As I re-read this post, it occured to me that all the solutions offered so far are much too high tech. What you want to do is take incoming analogue audio, turn it into "something digital", transport it across the network (to a bunch of places, as it happens), and then turn that "something digital" back into analogue audio. The Squeezebox will handle everything after turning it into "something digital" for you, providing you give it a format it understands.
One of the formats that the Squeezebox understands is a WAV file, which is basically a small header (with number of channels, sample rate, etc), and then raw A2D output. IIRC it's the only non-MP3 format that it'll play, at least in the older models. So what you want is a network service that (a) accepts connections, (b) picks data out of the A2D buffer on the sound interface, and (c) sends it out over the network as a WAV file (ie, initial header plus A2D data).
For the encoding part you could use something like arecord (alsa-utils) to encode the audio, eg "arecord -f cd -t wav" (default output location is standard out). Or sox, eg, "sox -r 41000 -w -c 2 -t alsa hw:0,0 -t wav -". (You might prefer "-f dat" -- 48000 rather 41000 samples per second -- especially if your input sound card prefers that; -r 48000 in sox will do the same.) For the "network part", this sounds like an ideal job for (x)inetd -- just run the relevant recording command when something connects, and it'll send the WAV header followed by A2D data until killed.
Then, in theory, you just point the controlling squeezebox software at the host with the (x)inetd setup and away you go. From memory it will receive one copy of the stream, then reflect it out to all the slaves, so that should work fine. If each slave is told to connect to the stream then you'll possibly run into problems with them being out of sync (and if you're not using alsa with a card supporting multiple connects, with some of them being locked out).
Sorry, no use of PulseAudio in sight.
PS: 48000 samples per second, for 2 channels, in 16-bit, is 1536000 bps (1.5Mbps). Even over a wireless link or a 10Mbps Ethernet that shouldn't be too big a load. If you have 100Mbps or 1Gbps connections I doubt you'd notice the traffic. You may need a bit of buffering if you're using a lossy link, as the audio is being "streamed" in a TCP connection, and hence you'll get retries.
PPS: Another cute hack: use the printer spooler to queue audio
(it was first done by the OpenBSD folks at a hackathon IIRC, but I can't find the original link quickly). It doesn't look especially difficult to repurpose it to submit into the SqueezeBox software playback queue. But of course it doesn't give you "plug iPod headphones into line-in and music appears".
PPS: The headphone jack on the iPod (and all other devices) and the line in on audio interfaces have different impedences, and IIRC voltage ranges too. So some experimentation will probably be required to get a tolerable output, probably involving not making the output from the iPod too loud (so it doesn't clip), but then amplifying it somewhat at the encoding stage (see, eg, sox man page). If the iPod has a line-out, that would match the sound interfaces line-in much better (no idea if the iPod does though; I don't have one). Beware also of earth loops, and all the other fun of using unbalanced analogue audio connections; providing the iPod is running on battery power -- or the same power source as the input sound interface -- you'll probably avoid most of those problems.