It's wouldn't be that special. All you need is to say that the out-of-range values are a niche of the type. For example, uint<6> would be represented as u8, but values 64 through 255 are a niche. Then at least from a theoretical perspective, the compiler being allowed to optimize this into a bitfield is a natural result of the representation being unspecified (combined with the inability to take references). Even from a concrete implementation perspective, the compiler could look at niches when deciding whether to optimize into a bitfield, instead of literally special-casing uint<N>.
Still, the use of a bit width would be confusing, as users might expect that to always result in a bitfield. But that's easily solved. Instead of defining the type in terms of bits, define a more generic 'integer in this range' type . For example, uint<0, 42> would represent an integer from 0 to 42. It would have niches from 43 to 255, and when combined with #[flat] would typically be represented in 6 bits. This kind of type would be useful for high-level tasks, completely independently from its use for bitfields.