It's an interesting idea, but I don't see it working out in the C++ standard library. Firstly, you can't truly leave the details opaque to the user because if the alignment guarantees of the limb array is unknown, any user code would involve some dead code that deals with weird sizes, even though the byte array always has a size which is a multiple of, say, 8. That constant needs to be exposed to make std::assume_aligned etc. usable and thus avoid overhead. Even if you didn't expose that constant in the standard, "clever" users would probably look into standard library internals and write code that makes alignment assumptions without our assistance.
And I would not want to throw type safety under the bus. Since you cannot create something like a std::span<unsigned char alignas(8)> in C++, nor an unsigned char* alignas(8) in C, every function that passes around limb arrays comes with preconditions that either add more UB to the language or require pointless runtime checks. I would much rather be able to represent a limb array using a type that carries all the necessary information.
Anyway, I can see how there is an ABI trap, but the most plausible solution is to contain it to std::big_int. The currently proposed std::uint_multiprecision_t would just be an alias for the limb type of std::big_int, with no additional connotation beyond that. There are ways to make the limb type more opaque, but they're kind of futile because it's not like you can arbitrarily change the ABI of std::big_int just because you've made the limb type opaque; it's still an ABI break.
To be clear, I'm not suggesting a big_int type for C, only the limb type that could be used internally.
The C version of the feature would likely end up looking like a stdc-prefixed version of GNU MP, and I'm not really sure how much benefit there is to standardizing that, or whether WG14 has any appetite for copying and pasting GMP into the C standard.