So a few more things to add to this:
First off I have since gotten photos of essentially the visible hardware I am trying to emulate:
Looking closer at the screen I am looking at a 128 height LCD of at least 240 width or better (if they can be found within reason!). In addition I have found this radio in a few places for <$100 which is really surprising to me but is a good price point I think to essentially gut it for just the screen and front fascia and possibly get an idea if the screen can be salvaged or has to be replaced with my own. At this point I am not 100% sure how that would go.
Since my initial post I have been looking over LCD options for this build. Either a) Buy the to-be-emulated-and-gutted unit and salvage the screen or b) find a suitable replacement. Unfortunately for both of these they happen to fall under a specific set of criteria: Easily connectable to an existing ARM device which usually limits it to ultimately USB or 4 pin serial (power, tx, rx, and gnd). This specifically kills parallel based displays it seems since there is no direct parallel-to-usb option that works. And to add salt to the wound, many LCD's I have come across that are 128 pixels in height are pretty much parallel based. On top of that, interfacing in software is complex in that everything would have to be written at low level unless there's libraries available for the specific hardware (which I have researched and seem to have limited hardware support in the ones I've looked at and thus restricts LCD options).
My other option which I have been contemplating is going the TFT route but once again designating a no-frills UI and trying to go a small LCD route if possible. In fact Sparkfun sells a PSP LCD which is 4.3" diagnol and 480x272 in res and great quality. Unfortunately seems no easy way to interface here either and VGA options are all extensive DIY projects. On the upside, if it is based on any sort of video output from the system, it is a bog standard and relatively simpler method of UI building just going with X and SDL or OGL.
So the hardware side is still in a state of flux at the moment.
Software side is slow but positive. Unfortunately my PogoPlug Pro board is not cooperating as much as I'd hoped. Mostly because the kernel is not as completely open like other ARM solutions on the market so everything is largely hacked together on this thing. My progress with this thing over the past couple days has involved reflashing my rootfs flash drive numerous times after it has failed to boot after doing basic software updates. At this point I am impatiently waiting on a TTL USB adapter to arrive so I can debug these and hopefully progress forward. I am possibly also looking at getting an RPi next time some are available to order at un-inflated prices just to bypass the annoyances and get this setup functional on a stable and well documented piece of hardware.
But I have looked into MPD and tying into PulseAudio and ALSA and all encompassing documentation and seems for those it should very well do all that I want and then some. For now I will probably have to test theories out on my headless Ubuntu machine and once I can sort out the PogoPlug or RPi I will move the setup over to that.
On a related software note I have put further thought into both NAv and Voice functionality and how exactly I'd like to manage that. Both solutions I feel are very intuitive:
NAV: My original investigation into linux based navigation software has left me fairly unimpressed and unsurprised at that. My initial thought was to use Google's existing routing functionality under Maps. As my research led into it, it appears going this route is practically dead simple barring programming geographical mathematics into the system. Long story made short, Google offers an API for directions where you can supply a basic lat/lon source and destination info (in nearly any format such as how Maps allows now) amongst other options and will return a JSON/XML feed with not only individual turn-by-turn steps but also a full parseable path-line of the full route and individual steps. To the point that in CarPC use could just have it send up the current lat/lon origin and desired destination and with the returned data, parse everything out so the computer can mentally map the path and determine remaining time/distance from current location and even rerouting based on how far off the path you are. In fact my theory is this is how Ford's Sync system functions when it pulls turn-by-turn directions from their phone 411 service. This will be a theory to test in full once I get a functional piece of hardware or a desire to dualboot a form of linux on my laptop again.
Voice: Along the same lines as above: Although not documented nor supported, Google has a pretty easily accessible service to utilize their voice recognition features which are very accurate. Given network access is available, this should be just as easy. To break it down it works like this: Record a voice command off the mic how you choose. Encode to either Speex or FLAC. Curl up to Google's servers and as a response you get a breakdown of possible results with the top being the most likely and an easily parseable text field. CarPC-side use some language rules to parse it out as you wish.
Now the downside to both is that they'd require network access to function (at least initially for Nav usage. Unless going off route or starting a new one, once started you should not need connectivity after that). Voice side is inevitable here and will likely be done instead with a linux-native package if something pops up that is suitable. I have not researched this part enough yet. Nav side I have been looking into a data-over-voice system which would negate 3G access and use voice service directly which should be relatively more reliable in corner cases. In theory this setup is completely doable but the million dollar question is getting reliable data modulation/demodulation over the garbled mess that is current cellular voice codecs. This part is definitely an end-of-project feature addition if at all, but worth pondering IMHO.
'Tis all I have for now. FYI: I do have my USB sound card and one of my first things to get going is 2-to-4 channel audio via ALSA and subsequently volume/balance/eq controls all in software so from the PC side it is just 4 channels of audio straight to a locked gain amp. More on this development to come!