The latest driver registered with Microsoft for the product you're going to spoof would need to have a vulnerability to exploit. You can't supply any driver.
This allows enforcing rules like "never add an additional keyboard". But the USB protocol has no support for strong device authentication, so there's no way to prevent a device from acting like a malicious version of something in the device class you expected it to be without abandoning "plug and play" altogether (a reasonable solution in secure environments where unused ports are often physically blocked).
This is what any decent barcode reader does, by the way; and before USB, they would be inline taps that pass through a regular PS/2 keyboard.
But you can't pretend to be any vendors id, only the ones with vulnerabilities. And the drivers or spyware will be downloaded by windows from the vendor's site, not from your peripheral.
But yes, usb device identifier is done through software/firmware.
A USB attack-widget isn't limited to just one VID:PID pair. It can present itself as as hub with as many VID:PIDs behind it as is useful. (This isn't new or exotic functionality; the very first USB thumb drive I ever owned did this as a built-in, maybe 20 years ago.)
So, for instance: A single physical widget can present as a thing that makes Windows install vulnerable software, and as a keyboard that issues commands hook that vulnerability, and as a storage device that provides a payload, while also [or ultimately] appearing as the fully-functional device that the user actually intended to use.
Game over.
The end-user might see a brief flurry of stuff happening while this goes on, but that's no big deal: End-users are already accustomed to seeing that kind of thing when new hardware is introduced, and clicking whatever button it is that they're required to click in order to proceed.
Better to just never stick strange USB sticks in your computer.
The BSDs have config, Linux can run without module support.