Generic pin headers are in the "pinhead" library. For something like the breakout board with multiple rows of headers, you can just place them in the proper locations on the board layout.
That said, do you even need to create a PCB? Since everything is on .100 inch centers, you could just get a protoboard, and solder your connectors on with point-to-point wiring.
If you want to go to the trouble and expense of making a proper PCB, you may want to consider starting from the Fio design files and integrating the motor driver on-board. The connections will be more secure, and you will save the mass of the extra PCB.
I'd like to place these additional CPLDs on a different PCB. This has the advantage that I can simply extend the device when I need. On smaller harnesses, a single 114 test-point PCB will suffice. On larger ones, I can cascade.
There are multiple levels of modularization which you can aim for. Where you want to stop depends on your specific use case. At the most basic level, the hardware must be designed such that you can select the number of modules in use after the design stage. The difficulty of changing the number of modules, space available, desired software complexity (and available space for software, especially on a CPLD) and the system cost will be key factors in your decision.
Hardware
The simplest and cheapest way to do this is to build one PCB, (You don't need multiple PCBs for modular design!) and put footprints for your desired maximum number of CPLDs on the PCB. If you need more IO, you can then solder down another CPLD. Obviously, this isn't something you'd want to do very often.
At the next stage, you'd want to build daughtercards so that you can more easily add and remove modules. You asked:
But what would be the best way to actually connect the PCBs together?
This depends on your system architecture and number of modules. If you know you'll never want more than, say, 3 modules at any one time, just put three connectors on the main board. These can be edge connectors, or stackable connectors, or whatever you like that doesn't require wires. If the number of sub-modules is too large to fit connectors for each on one PCB, then you should consider stacking (if your bus can handle the fanout of your maximum number of modules) or daisy-chaining (if you need to buffer the signal or vertical space is limited) the modules.
Plenty of connectors are designed for this purpose; check the "Board-to-Board" section of your favorite distributor or manufacturer, and many are designed for extremely low crosstalk and high frequency - 500kHz is nothing, unless you're using PTH 0.1" breakaway headers and have fast-changing signals (even then, you're probably OK). Check the mating strength of your connectors just to be sure, but if you only have a few pins, the footprint of your interconnection doesn't carry the stresses well, or the system will be subject to vibration, you'll need standoffs. It's often wise to design the interface in such a way that different modules can be designed to interface with the motherboard in the future. Pins are cheap, give yourself a couple spares just in case!
Software
If your number of modules supports it, you can simply add a slave select line for each module. This isn't really a software solution, but I wanted to mention it.
If you don't mind programming every CPLD differently, you could build the system such that the microcontroller sees it as one giant shift register (which you've suggested). If you added or removed a module, that module's address space would simply be wasted, and extra time would be used transmitting to addresses which don't exist. Each module would need to 'know' its address space, though, which would make programming the complete system a struggle.
A more versatile solution is to use software addressing to access each sub-module. In a 'programming mode' (perhaps a pushbutton on the module, or simply only connecting one at a time), you could assign the CPLD an address. By assigning each CPLD a different address, you could add or remove modules at will, and only have to adjust the activity of the microcontroller (which I presume to be easier to adjust than the CPLD).
My suggestion for this project
If a 324-pin device will solve all your foreseeable use cases, then the single-PCB method should work fine. The multiple-slave-select method would allow you to program all the CPLDs simultaneously with a single programmer. Sorry, but this project as described doesn't seem like a candidate for daughtercards.
Best Answer
A while back I hired an EE straight out of college. He asked me something like, "how do you prove out your designs? Do you breadboard them? Wire-wrap? How?"
My answer was, "Well, we build a PCB and if it works we go into production and ship it!"
Many circuits simple cannot be prototyped without making a custom PCB. Anything high-speed, low-noise, high switching currents, etc. are difficult or impossible to make any other way. Sometimes the logistics alone get in the way. You cannot, without a custom PCB or some crazy adapter/socket, prototype with a 1000+ ball BGA. Even if you could, you wouldn't want to. The odds of making 1000+ connections without error is very low. Doing it twice is almost impossible.
Making custom PCB's for prototypes seems expensive, but it isn't. Not compared with paying someone to make and debug several prototypes using breadboards or wire-wrap and even then ending up with something that is of questionable reliability.
So professional EE's usually go straight to designing a PCB and then doing everything they can to make sure that PCB works the first time. It almost never works the first time, but the closer it is to working the better it is. Then the board is modified (a.k.a. re-spun) and built again. With any luck a PCB goes through 2 or 3 respins before going into commercial production.
I recently did a custom PCB that used an Intel Atom PCB and all the usual PC type things. My approach was no different with this PCB. I designed it, tried very hard to get it to work the first time, and built it. The Rev 1 PCB's mostly worked, but has some minor issues. The Rev 2 board worked perfectly.