thank you Kevin for that answer.
In the meantime I've discovered a few more facts, which I'll detail here. I'll also file some bugs and attach their numbers here.
I did manage to get a PCI driver to match and install on a victim machine. I used an Xcode-generated profile that includes our own PCI entitlement, but installed the driver on a machine with entitlement checks turned off. To do this, on the victim machine:
boot into recovery and turn SIP off (csrutil disable at the command line)
boot back into the OS, and execute:
sudo nvram boot-args="amfi_get_out_of_my_way=1 -arm64e_preview_abi dk=0x8001"
reboot to let the boot-args take effect
change the architecture of the driver to arm64e (it was ${STANDARD_ARCHS} (in build settings/architectures)
It is possible that not all of the boot-args are necessary. I had to change the build architecture because it seems like the other arguments make the OS think that everything is a platform binary. The driver still failed entitlement checks until I added dk=0x8001.
All of this information takes a lot of searching to find (some of it comes from these very forums)
I then tried making a USB driver for development (for a vendor ID we don't have an entitlement for). On my usual Mac, the driver won't load because the entitlement in my provisioning profile is for a specific vendor ID - I can't choose the development USB transport capability. I would have to deploy this driver on a victim machine with SIP off and the same shenanigans as above. This probably wouldn't affect a team with no USB transport entitlement at all, they'd only be able to choose the development flavor of the capability.