If I understand correctly you have 2 devices connected via UART. I assume just TX, RX and GND lines connected between the devices? (i.e., no DTS/CTS/DTR/RTS control lines used - this is typical).
In this scenario, device 1's TX (transmit) is connected to device 2's RX (receive), and vice-versa. Their grounds are connected to each other. Thus, each device can be transmitting and receiving at the same time (each transmits on a separate wire, the communication is full-duplex).
The reason I mention all this is because it becomes clear that to "sniff" or "listen", you'll actually need 2 UARTs to listen to both sides of the conversation.
Basically, all you'd do is ensure that all 3 devices' UART GNDs are shorted, and connect (really, "tee", as in a T-fitting, like plumbing) device 1 & device 2's TX lines to the 2 RX lines on 2 UARTs. Make sure that the baud rates are all configured identically.
There are a lot of Arduino boards / designs. The most common one nowadays, the Duemilanove, uses the ATMega328P, which I think has only 1 UART (well, USART). So you'd either have to wire up a 2nd UART IC, or resort to "bit banging" on the second receiver.
Async UART communications is well-defined, with start & stop bits (and sometimes parity bits), so if your processor is fast enough, you can simply connect one of the device's UART TX lines to a GPIO configured as input, and poll the line fast enough with oversampling to detect START & STOP and sample bits. The article "Bit Banging" by Jack Ganssle will give you plenty to chew on.
A decent description of the RS232 waveform can be found at BeyondLogic.
Note that there are other issues such as voltage levels (0/+5, -10V/+10V, etc.) that you'll have to take into consideration (see the Beyond Logic section on "RS232 Level Converters"). I don't have enough information on your system to discuss hardware interfacing besides the "connect the lines" approach discussed above. Assuming voltage levels are matched, usually it's not a problem to "tee" the TX line into a second receiver (the sniffer), but if the TX doesn't have enough drive, you might need to insert a buffer/driver to prevent the signal from degrading.
I suspect that most shield designers either don't think of it or run out of time. When I've made shields (for personal projects), I've had intentions at the start of adding other features, but by the time everything is laid out, I just think, "OK, this will work. Maybe I'll add that other stuff on the next rev."
Adding blank holes for hacking on extra stuff is a great idea. Given that most (all?) of the shields on Sparkfun are open hardware, why don't you make an improved version? I suspect that the Sparkfun folks would be delighted to accept your improvements.
Best Answer
I think that your best bet would be a Linux based system. Something like Beagle Board.
Arduinos and their ilk tend to target low cost microcontrollers.
In order to stream video over a wireless connection, you're going to need a fast processor and a fast wireless link. I'd pick an ARM based system, running Linux with WiFi.
Here's an example of what can be done with a BeagleBoard: http://mechomaniac.com/OpenCVBallTracking