Mere moments ago, quoth I:
1. Render it as a bitstring first and then use string comparison. This seems needlessly perf-hungry (unless internal storage were already as a bitstring, but that seems needlessly storage-hungry). This also biases the comparison to the non-[0] end, which might be good or bad depending on usage.
Variations include zero-padding whichever one is smaller, or not.
2. Compare each 32-bit (or whatever window size is convenient) group of bits as an unsigned integer (zero-padding if smaller than the window size), starting at whichever one holds [0] and continuing as long as both sets contributed at least one "real" bit to the window; if any comparison returns unequal, that's the result; if all comparisons return equal, then finally compare the actual sizes of both sets for the final result. Advantage: fast. Disadvantage: the ordering might change if the window size changes (eg. for different platforms, or future Boost versions).
Another variation is to start from the non-[0] end. This would probably get you a more "natural" bitstring-like ordering and should be less dependent on the window size. Might still result in different ordering on big-endian vs. little-endian platforms, though that depends on how internal storage is structured vs. indexing. Comparing the actual sizes at the end if everything else is equal seems like an important step, though. 0000 > 00.