I really have to agree with lawnJelly's thoughts here. In the long run, making a reusable piece of code that can handle any text you throw at it is the best course of action. Speaking from experience, it doesn't take too long to learn XML. It's not a proper coding language like C#, it's just a neat way to store data. If you want to learn to write it and make it so C# can read it using Linq-to-XML, it'll take a week, max (it took me two days, if I remember right, working about five hours a day, and it was working the way I wanted it at the end).
If you want to visualise the text itself well in the beginning, Greedy Goblin's suggestion is good. Twine is another (possibly simpler) piece of software that can do the same.
Making an engine isn't something to be especially worried about. It can be as small as you need it to be. For a text adventure, it probably won't need to be that big. In the case where you're using XML, it means you'll probably have a bit that reads from XML (you'll want to decide on a good format for it) and... well, that could be near enough it. Your XML file would probably consist of scenes, where each scene contains options that are linked to the unique ID of another scene. You'd want your code to recognise which option the user chose and then read the next scene from the XML file. This may be easier with set options (the user types a number to pick one), but it would be doable with input text as well. To build a full parser is a nightmare, though, so I wouldn't go trying to build something like The Hobbit Text Adventure right off the bat. If you want to manage objects etc. you may need to think a bit bigger, and I can't really give any advice on that.
It may seem more complicated at the beginning, but it means all you need to do once it's working is bung stuff in the XML file. And Linq-to-XML is definitely a good skill to get to grips with.