Clearly, some software had to be written to test the device. And of course, it had to run under Linux...
Fortunately the Linux kernel (I was using version 2.6.5) comes with support for USB-to-serial converters and there is an USB-FTDI library for download (check the links on FTDI's home page). Applying this library, quickly writing the test code was pretty much straightforward.

I am providing the test code here; it is a quick hack and can be used to test the read and write operations in bitbang mode as well as send and receive in normal (handshake) mode. Note that you need to download and compile libusb and libftdi (see FTDI's home page) prior to compiling this code.

Max bitbang mode send rate is 500kb/s using the available sources and 800kb/s using a patched libftdi (with non-standard baud rate). However, note that this data stream is not continuous but comes in bursts of 64 bytes.

For normal (handshake) mode, the data send rate is independent of the used baud rate because the handshake signals and/or the USB limit the amount of data transferred. Here is a smaple ternial snipped using the above program and applying a 1MHz clock to the WR pin of USB-CTRL:

bash# ./testusb send
init: OK
open: OK
reset: OK
bitbang(off): OK
baudrate: OK
................................................................................
................................................................................
..................[interrupt]
written: 729088 bytes in 0.904 sec (787.611 kb/s)
close: OK

The data sheet mentiones a maximum transfer rate of 1M/s for D2XX drivers (Windows only) and 300kb/s for VCP (virtual COM port) drivers. The measured >780kb/s (using libftdi drivers over USB-1.1 with max. 12Mbit/s, hence >1M/s) are hence probably not at optimum.

It is often desirable to use one's own vendor and device ID for the self-made USB device instead of the built-in FTDI defaults. This will, e.g. prevent the Linux USB device module loader to automatically load the ftdi_sio module when you plug in the board and allows you to have your own actions taken upon plugin. If you ever intend to use more than one FTDI chip on the same USBus or your device needs more than 50mA from the USB, you most certainly want to program your own EEPROM contents.

In order to read the EEPROM content and to write own information into the EEPROM, I wrote the test-and-demo program testeep which can be downloaded here:

Please look yourself at the code for details. Here is a shell snipped for my board:

bash# ./testeep -d=6002 dump
init: OK
open: OK
reset: OK
read eeprom: OK
EEPROM Content:
  vendor=0x0403,  product=0x6002
  self_powered=1,  remote_wakeup=1,  BM_type_chip=1
  in_is_isochronous=0,  out_is_isochronous=0,  suspend_pull_downs=0
  use_serial=0,  change_usb_version=0,  usb_version=0,  max_power=0
  manufacturer="WieserLabs",  product="USB8bit (prototype)",  serial="1.0"
close: OK

In case you get an error like
open: rv=-5, error=unable to claim usb device. You can still use it though..., errno=Device or resource busy (16)
make sure that the ftdi_sio module is not loaded (and the FTDI driver was not compiled into the kernel). Using libftdi, one can access the USB device without usbserial and ftdi_sio funcionality present in kernel.

An error like
open: rv=-3, error=(null), errno=Success (0)
will normally mean that no device with the specified vendor and ID is connected. This normally happens when one changes the EEPROM content with one's own vendor and device ID and forgets to use the appropriate -v= and -d= options for testusb/testeep.