Incidentally, I took a look at the code and empirically tested a clone device to confirm.
I found another interesting (unicode) string in the ftdibus.sys file: "The FTDIBUS driver detected a Type 1 counterfeit device and will disable this device." (and the same string with 2-5 instead of 1, can't they use sprintf in a driver?). Can't find the xref with my IDA Pro disassembler, when is it used?
I'm not a Windows expert, but I believe those are translation/textual string resources used for the system event log. Messages are logged by code, so there wouldn't be a direct xref there, instead that's a table that maps codes to strings and something inside Windows itself does the mapping - so yeah, they can't use sprintf, this is Windows' dumb design I think? (someone with more Windows knowledge might be able to correct me here). I did find the logging code earlier, and what triggers it, but didn't check if it is indeed logged on my windows box. I just did and yeah, it's there:

Of course, they
say they'll disable the device, but then go ahead and corrupt its data instead. Nice definition of "disabling".
Types 1-4 mean integrity checks on EEPROM addresses 0x40-0x4f failed (which seem to store manufacturer info, perhaps non-writable? haven't tried, the normal EEPROM user/config area is 0-0x3f), while type 5 does the good old 16-bit EEPROM writes check (what they used to brick devices in the previous version, except this time they revert their changes). It actually writes a 0 to the PID field (without fixing the checksum to match), reads it back, and restores it if written (original chips won't write it as its address is even). Amusingly, all of this is still wrapped in a "if EEPROM checksum is correct" conditional, so you can still use my Python tool to deliberately corrupt your EEPROM which will make the chip work with the official driver (if you're okay with all default configs and no serial number), but even better, if you plug it into a Windows machine with the new driver and unplug it at *just the right time*, the written PID field will cause a checksum failure and the driver will start to work fine with that device!