NBDE (well, clevis) is really just a way to get password for a LUKS keyslot over network, there's not much to "integrate" with. Maybe a generic usbguard rule match for drives with LUKS metadata, so anything non-LUKS would be blocked/rejected, but then you run into issues of partitions and the entire solutions becomes pretty "hacky".

Plus it can be easily faked via a fake LUKS header ie. in the first few-KB-wide partition, with the unencrypted data in the second one. Or with a partition scheme usbguard wouldn't anticipate (ie. GPT, Apple Partition Map, etc., all of which are recognized by the kernel).
Even if we were to allow only no-partition-LUKS, it could still be faked via a number of other ways.

What would make more sense to me instead is to provide another layer of security by using (generic) signatures at the beginning of the USB drive, possibly authenticated using tang (the "server" in the NBDE scheme), independently of whether the drive (or any partitions on it) is encrypted or not.

I don't think the signature option can work. The signature would have to sign data reported by the USB device itself (such as manufacturer, product, serial, etc). However, this data can be easily spoofed by readily available and inexpensive programmable hardware. This would mean that an attacker could easily copy the signature from one device to another in order to foil the device level authentication.

Since we are depending on specially crafted partition/LUKS/clevis layouts anyway, we can just define a very narrow format we support and reject all others.

Let's make a threat model. We assume that the goal of the attacker is to exfiltrate data on a trusted system using a USB key.

1. The user creates a normal filesystem with or without a partition table. USBGuard should reject this and allow only LUKS.

2. The user creates a LUKS device without a partition table. However, the user knows the LUKS password. USBGuard could check to see if there is clevis metadata with luksmeta.

However, since clevis itself listens to password prompts, the attacker could simply fake clevis metadata and then answer the prompt themselves with the known password. In order to bypass this, we need a way to disable these prompts.

This means that clevis needs to take over LUKS unlocking. A much less invasive change would be for clevis to define its own on-disk format and handle its own unlocking. In this case, clevis could define that the disk is non-interactive and would never prompt the user at all. USBGuard could then allow only these non-interactive volumes.