I'll answer the challenge.
The number of pages is only limited by the number of posts that can be uniquely referenced in the vBulletin software. There's nothing really persisted in the data regarding a page other than one or more page size configuration settings. The pages may be cached on the server for improved performance, but that's not a vBulletin feature.
The number of posts is limited in an absolute sense by the data type that is used as an identifier for each unique post. I assume that vBulletin uses Globally Unique IDs, so the maximum number of posts that could be stored for a single implementation of vBulletin software (such as Tidefans.com) would be:
5,316,911,983,139,663,491,615,228,241,121,400,000.
So, if all of these posts were on a single thread, divide that number by the configured page size and that gives you your maximum number of pages.
However, displaying the actual number of pages in a post might actually be the breaking point because that would be displayed as an integer (32 or 64-bit) and the maximum number that a 64 bit integer could handle would be 18,446,744,073,709,551,616. The page size that would correspond to that number of pages and the maximum number of posts would be almost as large as that number itself, which would make the page impossible to load in a typical browser and even store in application memory on a typical PC.
Also, the amount of storage required to support that number of posts would be cost prohibitive for Tidefans and searches could 10 to 15 minutes due to the size of the indices.
So, for practical purposes, as TIDE-HSV and crimsonaudio pointed out, the limit can be considered beyond the scope of consideration.