I don't really want this either; I'd rather the program abort. The vast majority of situations where I'm using signed arithmetic, I never want a positive number to overflow to negative (and vice versa).
Unsigned arithmetic is already designed to wrap back to zero; that's useful for things like sequence numbers where wrapping is ok after you "run out".
The ARM mode described elsewhere in the thread where there's an overflow flag that persists across operations would help; then you could do a check less frequently.
A mode were you get a processor exception would be great, if adding that doesn't add significant cost to operations that don't overflow. Assuming the response to such an exception is expected to be a core dump, the cost of generating such an exception can be high; of course if someone builds their bignumber library around the exception, that won't be great.
A predictable branch is basically free. In your case such a branch is almost never taken.