You should have a model manager (or a higher level resource manager) which you load models into, meaning each model is only loaded once. Objects in your map will contain a pointer to a model, and then transformation information and any other info it needs.

The reason maps are "random symbols" is because they typically store their data in binary format. They usually just serialize C/C++ structs directly to a file so in your runtime when loading a map you don't have to do any unnecessary parsing/calculations.

For terrain you'd just use heightmaps and include tools in your editor to raise/lower sections, smooth out parts etc.

A map editor is supposed to do, what you want it to do.
What does your game need? I discourage you to make a map editor just for its own sake.

Make a game, make the editor with it. Design the editor in a way, that you can easily add more and more features later, as your game needs more and more stuff.

Building a map editor for it's own sake is almost like building an engine for its own sake.

But maybe I misunderstood something...

It's not easy, I can tell you that. At least not easy the way I (tried to) made my own once.

I used OpenGL and vertex arrays. I made it out of quads that I stored in vertex arrays of 8x8 quads and that I culled against a sort of threedimensional quadtree.

The way I stored the vertex data ended up being a complete mess, primitive classes with pointers to the values in the array. Completely un/mantainable/modifiable.

I got to being able to do some mountains with an sphere algorithm and got stuck trying to do multipass rendering and never went back to it again.

I hope you luck though!

Writing an editor is indeed almost as much work if not more than the game [engine] itself. I worked on a commercial product that was almost nothing but an editor and it was an endless uphill change and maintance battle for 3 years before it reached the point were it was usable on a constant basis without people outside the development team moaning for a new feature or another way of process flow. The data structures changed from day to day and were not backwards compatible for some time until we switched to using a declarative binary file format. We called it FLOW (File Loading and Output Wizard) as a nod to the people that would want the program flow to change all the time.

You described data structures in a FLOW script and "compiled" them in cpp/h files capable of now saving or loading that data file. The interesting thing was that if the field names stayed the same but changed format there were converters if they were single like int to float or double to string. You could also define conversions if they were a little more complicated.

Our main goal was to basically add and try not to take away making it easier to support previous file formats we created. This also allowed to some degree older versions of the program being able to open up files created with a newer version as well.

We also had an abstraction from the editor object and the runtime object. The runtime object was basically just what was needed to allow for end user interactions and rendering. The editor object changed constantly more so than the runtime representation and we had a final "process" to distill all the info for the release data. So in many ways we had two very distinct views of an object.

Another thing to consider is that a lot of work will have to go into the user iterface itself no matter if it is fully graphical or not. Historicaly from many source this turns out to on average to be almost a 3rd of all your code and when things go wrong it will also account for more that half of all the bugs you will encounter with your own work.

Indeed "Do I need this?" is something you should be asking youself all the time. Never do more than you have to and always think what is already at hand that with little or no work will give you the same outcome or something close enough that is acceptable. Simplest thing I ever did was use MSPaint as an editor. I basically created and arbitrary set of rules like each pixel represented so many world units and each color represented a different object to be placed in the world and wrote a small script that converted this into something that my engine could easily use. Also look at using file formats that already have code available to load and use free tools that export into this format. And if you are still set on doing your own editor look into leveraging available libraries like AntTweakBar to speed up development and even just to ease your own usability even if it is just for yourself. Never feel bad about using what is out there because even the professional game companies do and even license other peoples libraries all the time.