Repetitive data structures are what hashes and maps are for ... Unless Stardock did a brute force approach I'd be surprised if more then meg or two is used. Plus 8-12 byres per unit (A hash/map reference, a HP counter, and a units X/Y position stored as a 16-bit integers.) Maybe a byte or three more storing a birtwise flag or hash for spell affect(s).
Tiles could be summed up as a constant reference to a hash or map entry. IRC, In C that would be a extra pointer to deference, in C++ that would be machine code to literally be the object in question. Making each map tile no more then a single 4 or 8 byte structure. With the map consisting of a few dozen or so unique tile types and/or city improvements.
Storing each unit's equipment list on each unit would just be silly. (Especially if you used an array. Simply allocate the array once, and as an array is really just a fancy pointer, each unit types just stores that array's address.) Unless their using a data dated C/C++ standard (AKA visual studio's, oh how I loath Microsoft's "We can not only do it better then you, but force it down your throat approach." approach. I especially loath C#.) A good chunk of the C++ and resonantly finalized C++0x standard are devoted to efficient memory management.
Even then, the actual management of memory is the OS's providence and what a "swap file/partition" is for. It may slow things down if a program thrashes, but I don't image the actual memory limit is in fact THE limit.
If you've every done any low-level memory management systems, physical memory is a limit, but it's nothing more then a soft tissue paper barrier. Your actual limits are your imagination and how much processing power your willing to divert to keeping things small.
----
Which is just coder speak for, What's it matter to you? Unless Stardock sees fit to hirer my meager self or the "?humble?" reader on the spot and say "Here is the source code, improve it", the thread is just a fun romp.