[camlorn]

I'm going to chime in here and say that i agree with Dentin-my mud projects failed because of over design.
Disregard html and databases. Disregard account creation. Nothing is wrong with help files actually being files, but even disregard that for now. You are months away from needing a newbie tutorial and--depending on how fast you go--weeks to months away from needing a coherent mythology and world. I'll come back to tutorials at the end.
If you are going to make a codebase from scratch, here's what I'd have to say:
-start with an echo server. This is simple, typically about 50 to 100 lines, and examples can be found on the internet,. Code from it will probably not survive into later steps, but it will teach you about sockets. All it does is send every line you send it back to you. If you already know about the c/c++ notion of sockets, not the javascript one, you can skip this; even so I wouldn't. You can use a number of frameworks, but which one you use doesn't really matter, and Berkley sockets is good enough for your purposes.
-from there, disregard account creation and make a server that lets you walk around in rooms. They can be hard coded, it doesn't matter. The server will ask you for a name but doesn't care about password, and nothing will be saved. You can log on and walk around in rooms, no authentication. After you have that, make it read rooms from a file. If you call them rooms a, b, c, and d that's fine, not important at this point--this isn't your world. Implementing say at this point may not be a bad idea. This will give you a starting point to build off of.
-from there, you can do a number of different things, but I'd look at two of them specifically: character authentication and simple building commands. Don't worry about e-mails or linking with accounts. You want to be able to make a new character, and you want to be able to log into said new character again later.

If you need to get stuff to the web site, you can always make the mud into a tiny web server, or make the mud write out HTML files, but I'd not worry about that right now either. If you don't know databases, get everything working with files first and have a game that is at least playable. If you know SQL well, there's nothing saying don't use it, but it's not something I'd try to learn at the same time as everything else. Flat files are good enough for very, very large muds. Come back to the HTML side of it later, and you can use websockets from c/c++. You don't need a web site yet.

And the promised return to tutorials. After you have implemented a combat system and a way for builders to build stuff, you can look at this. If you haven't implemented a scripting language for builders, I'd wait a bit longer-being able to put signs in rooms works, but is boring. You don't typically hard code special rooms in c, you let builders code them in lua or mobprogs or whatever you implemented. If you have to recompile the mud every time someone has to fix a typo or script in an area, your builders will hate you and so will your players. Newbie tutorials--if your system is powerful--can be done entirely by builders, and this will ensure they can implement cool quests for you too.

Finally, nothing is wrong with using a preexisting codebase. You can modify that--so far as you don't try to go a hugely big distance outside the box--easier than you can code one from scratch. Finding a well-commented mud codebase will not happen.