NIST SP 800-38A ("Recommendation for Block Cipher Modes of Operation Methods and Techniques "), Appendix B states that "The standard incrementing function takes
[x]m and returns [x+1 mod 2^m]" (my formatting, they used typesetting to show exponents). Section B.1 goes into more detail about recommendations for the CTR mode incrementing function.
Regarding standards and compliance (which usually force portability), I couldn't really say. And even if it was standardized to be done that way, that doesn't mean there aren't non-compliant implementations, and it doesn't mean all implementations are bug-free.
So, I guess my best answer to you is that while most implementations probably do that (wrap around like an unsigned number), and you can test it with different platforms, I don't think you can count on it, and I don't think you can scream if a vendor /changes/ this later to behave differently. I'm not sure there is anything worded strongly enough that you can point to that would back up a complaint.
Edited to add: The NIST document is interesting reading. For recommendations on the incrementing function, (here I'm paraphrasing / summarizing), it basically says the incrementing function needn't necessarily increment w/ wrap, it simply must provide all 2^n unique values for an n-bit counter. So for example, an LFSR or LCG could also be used.