Behavior of AES-CTR with 128-bit nonce and possible overflow
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.