I certainly can't claim to be an expert, but I'd be happy to give an overview of the process, unless someone else gets to it first. I'm not sure how much of what I know is applicable to their toolchain.
The toolchain I was using is several years old now, so probably not really useful, but here goes.
For 2.5D I usually used a CAD program to do a DXF drawing which I would bring into either ACE Converter (free open source program that converts DXF directly into tool paths), or SheetCAM (commercial, supports a variety of milling, pocketing and tracing operations).
For 3D I'd use Blender to model the part, then I'd import it into MeshCAM (commercial) or some free package with few features that I can't remember the name of to generate gcode.
I'd save the gcode to the network, then on the machine I'd fire up the Win98 GUI to use the network to copy the file over (batch file in startup, just copied everything from a fixed location on the network, then dropped back to DOS mode). Back in DOS I open TurboCNC (shareware, source with registration) and set up to run the code.
A similar modern chain would probably be about the same, just using something like Universal-G-Code-Sender to send gcode to an Arduino-based machine controller instead of mucking about with DOS. You could also use LinuxCNC (that's what the CNC mill at the Makery is running).
You could also use a suite CAD/CAM package like MecSoft's tools (there are a number of these out there, and they are all expensive), but generally the output is going to be a gcode file that you feed to your machine via whatever interface it supports.
It would be pretty cool for a small machine to use an integrated CAM/CNC controller package similar to the 3D printing software, so you go get a model somewhere and just have the one package to consume the model and run the machine. Like you were saying earlier, that would make the process much more accessible.