You think like an engineer! That's the exact list I had to go through. In my case, I've figured out the first two of those steps and use leetlauncher and the configurable launch scripts to take care of the third. I've been looking into actually modifying the AVIC rom and writing it out to the unit to make it permanent, but I'm saving that for a later date.
Ok, the first point on your list. Our unit (Standback tuner) was made to be connected to a PC and so we only had PC drivers for it. When dealing with drivers for a usb device, you usually aren't dealing with completely custom drivers. Most usb devices have a single chip that the usb wire is connected to. It acts as the middle man, converting commands from the usb bus to commands the actual electronics are expecting, usually 5v TTL. Because our device uses a standard usb controller chip (an ftdi chip) I was able to go to their site and find drivers for that chip that work on PocketPC and Windows CE devices. Then I only had to modify the driver's .inf file to specify the "code" that identifies our device uniquely (So windows can differentiate between multiple devices that use that common chip). To install the driver I made some registry changes and copied the driver file into a Windows system folder. It was a pain but I made a script that did it for me and just launch that when the avic boots.
On the second point, you can't run Win32 apps on an arm based device. There are two types of applications: managed and native apps. You have absolutely zero chance of running native apps as they are compiled for the specific processor of your target platform. Managed apps, like those based on .NET framework can run on a machine as long as the right .NET framework is installed. The problem is that even if the software you are trying to run (the software that came with your cable) is a .NET app, its still not going to work. The reason is that PCs have loads of resources and run the full .NET framework. Windows CE devices are skimpy on resources and run .NET compact framework. You can't run an app compiled for one on the other. SO, you have to write your own software (like I did) or you have to find a version of the original software built off of the .NET compact framework. I doubt they ever did that as Windows CE devices were probably never in their sights. For me, I had already written the original application for the PC so I just copied and pasted the code into a new .NET compact framework project. I then had to clean it up since many of my beloved commands and interfaces weren't available to me in the slimmed down compact framework.
Good news is you can write your own app as long as the api is available for your cable. If the cable uses the same ftdi chip everyone uses then you can get the driver working. Once you can talk to the device, you have to know what to "say" in order to get the thing to spit back the info you want. And then you have to know how the info it spits back is formatted. All that covered by an api. If there is an sdk or documented api for how to talk to your cable once the driver's installed, you have a chance to make it work with my software or with your own software you write.
That's the same for everyone else who have made suggestions about cables or devices to try. My software can be made compatible with them all as long as I have a way to talk to your device AND know the device's "lingo". The driver is the easy part, then I need to know the api. If the company has not provided the api to the public, then you'd have a long road ahead as you tried to reverse engineer their .dll files which are probably where they store their interfaces.
If any of that is over your head, you can always wikipedia it or ask me on here! 