Yes, and this would bloat the std::big_int container considerably. std::inplace_vector and std::vector make for 5 pointers of size combined, whereas our std::big_int is only 2 pointers large.
Overall, it's pretty unclear what you stand to gain. Allocating is not the hard part, but managing the transition between the small values and dynamically allocated values. It would perhaps be possible to have a std::small_vector type wrapped by std::big_int, but that still doesn't let you do things like pack the sign bit into the size to save space, so you would at least waste one pointer of size.
There are also domain-specific considerations like the fact that a 31-bit size already gets you 137 billion bits, which is more than anyone will realistically need, so it is wasteful to use a full 64-bit size.