I tried something similar a while back, where I had to get more parrallel data to a 320x240 LCD display to make it work, than the RPI had available. So I used some GPIO bits to sync and reset and a single GPIO bit to populate a number of enjoined shift registers, then some more GPIO bits to send the data to the LCD.
The ability to serialise something is the easy bit. The hard bit is decide on and implement a protocol that'll support the clocking of your data (and when you're starting/ending the transmission).
You probably need to decide from the outset what the data is going to be received by, to decide what a generic data transmission looks like. Is it a fixed size, so you can infer the end when you know the beginning, or is it variable (like a jpg).
There are protocols like RS232 that endeavour to manage the data reset/start/clocking/end signals within a simple twisted pair of cables (although you can have extra handshaking connections), but to do that you need to consider the kit for sending on both sides of the communication line.
So to answer your question, I'd start by deciding what you're trying to achieve, and how much complication you need to add to the Pi, in order for the data to be received at the other end. A parallel bus is easier to implement than a serial one (in terms of hardware), but normally you start from the bit of the problem you can't control, which is normally what you're connecting to the Pi, rather than the other way around.
Once you've got your hardware sorted, I suggest investigating the wiredpi application, and libraries, to write C code that talks GPIO, but as discussed you'll probably find it easier prototyping Python.