Sounds simple in theory, I need to figure out where I can learn how to write XML files.
Don't worry too much about 'XML'. It's just a file format for saving data, there are many and they're mostly interchangeable. E.g. these days JSON tends to be preferred due to it wasting a lot less space, or in network communications binary JSON is even used to reduce transmittal bandwidth even more.
I would suggest you look towards making your data into serializable objects instead. In nearly all systems there are libraries available to save these serializables into whatever format you wanted (be that XML/JSON/Binary/Database/etc.). Which in turn means you also don't tie yourself into one specific format and can much more easily change later if you run into a need for such. But most importantly, you'd not need to re-create your own format parser - which is a very complex task and is very prone to errors (much better to use a tried and tested library for such).
To get to this system, your first decision should be how you're going to record that any particular object should be "linked" between these drawings. Is it going to be in some extra file, how is that going to imply such links? E.g. is there some identifier in all programs which allow a way to uniquely map a specific object to another in the other program? Do you want these updates to only happen on a specific event - e.g. when opening the file, or when you click a button, or should they happen immediately? Or would you just re-create the objects every time? These things my be affected by specifics regarding the various programs APIs and what capabilities you get from them.
Next, you'd most likely want to create your custom programs in some similar environment. Just so you don't need to learn 3 different languages and environments. E.g. in ACad you've got 4 choices: C++ with ARX, DotNet, AutoLisp and VBA. In Rhino you can do such using Grasshopper, Python, RhinoScript, RhinoCommon (DotNet), C/C++, etc. So it seems DotNet / C++ is probably a good choice. You may find that Sku is where you're gong to find it difficult, you basically have C or Ruby as standard. This may be especially important if you wish to have a live link between running processes - e.g. as you change the object in ACad it immediately updates in Rhino. If you use some form of polling process (e.g. saving to external file and then reading from it later) it would just mean you need to write two (or three) different programs in different environments.
Personally, I'd rather attempt to do as much as possible inside one single program. E.g. use C3D for all of it, perhaps using 3ds to render if needing more than ACad's own renderer. However, I'm not extremely versed on civil stuff, very long since I did any civil drawings. These days it's much more abut architecture and Revit being the major player in that game - so I don't need Sku/Rhino at all. Though I would definitely not recommend Revit for anything even touching any civil project, it's simply not designed for that (just a personal gripe since Revit and any site related stuff is just irritating to say the least).