From checking the Windows drivers for the touch screen, the actual hardware is a PenMount unit. This is fairly predictable, since it is a Dialogue product.

Linux appears to already have a PenMount touchscreen driver as part of the X package. However this only works with standard serial or USB connected PenMount panels. It appears that the Flybook PenMount panel is connected via a non-standard serial port (no idea why, the rest of the Flybook peripherals are connected by standard USB or serial buses...)

In Windows, the PenMount driver hangs off the PCI-ISA bridge and uses IRQ 6, address range 0x338 - 0x33F. Trying to register a serial port with setserial /dev/ttyS1 port=0x338 autoconfig doesn't result in a usable serial device (kernel complains with 'LSR safety check engaged!' - indicating no UART found at that address).

Further investigation involving looking at any tell-tale strings in the Windows touchscreen driver, implies that the Dialogue Flybook PenMount driver (called PenMount LPC, presumably this means 'low pin count' as in other integrated tech solutions) is a hacked version of the i8042 driver. This chipset is the legacy keyboard and mouse interface, and usually resides on 0x60 - 0x64 with IRQ 1 (IIRC). Perhaps the Flybook touchscreen will work as an i8042 AUX device (mouse) if a driver is installed to do the same stuff as the existing i8042 driver, but operating against 0x338 - 0x33F and IRQ 6. The address range and IRQ seem to be hardcoded in the header file for the existing i8042 driver in the Linux kernel source, so another driver may need to be written.
I could have got completely the wrong idea about this, but the touchscreen resource isn't on the USB bus anywhere, and doesn't seem to be detected by either Plug'n'Play or ACPI for interrupt routing, so may be more basic, like a keyboard driver...

This sort of thing is way outside my expertise, so I'm going to need help here from someone who knows how to develop Linux kernel drivers.
There's a thread going on at Handtops.com regarding this, please add to it if you're a hacker with the answers!

Alternatively, we may need a custom kernel driver to present a standard serial interface to the system. I'll update this if any solution is found.