As others observed, "one" is only useful for the "bit" method default, and might be meaningless for an "instance () Bits" (whereas the rest of the class makes sense for () as a zero-bit instance, albeit a use doesn't come to mind). Or, similarly to (), a bit-vector which contains its length statically in its type: it would be simpler if length zero was just as valid as any other length. And it would be a bit strange to define 'one' as a value equal to 'zero'.
It isn't entirely meaningless it is just out of range. It is perfectly well defined for me to set the 200th bit of a 64 bit integer, it just doesn't do anything. ;) Similarly setting the 1 bit of () would result in (), since there are no bits to set.
This is hard to implement in practice, as the behavior of assembly instructions for bit manipulation isn't always defined on out of range values and working around that problem in Haskell code will often involve a bad performance trade-off (i.e. adding a branch). We have this problem with shiftL/shiftR, which are terribly slow, leading to no-one using these functions in production quality code (I think I've seen unsafeShiftL/R implemented in at least 3-4 of our most commonly used libraries).
I suggest we hurry slowly here. Do we understand what the meaning of the Bits class is? Lets make sure we don't make it harder for use for the majority use case of performing bitwise operations on machine sized quantities.
Cheers,
Johan