Since DBs do not reuse numbers of deleted records it is possible to run out of numbers, especially if you pick not really a big integer type for this column.
What would
You end up with a 3+ Hour Downtime, like Slashdot did on their Comments-Function.
I tried this in SQL 2000 some time ago. After Integer.MaxValue the next identity value is Integer.MinValue. It then keeps counting up as you would expect. As long as the records that used to exist at 1,2,3 etc have gone by the time it gets there nothing bad will happen. If it runs into a duplicate (and the field is the primary key) then the insert fails with a key violation. I haven't tried an identity column that isn't constrained to unique values though. I would guess it would be happy with the duplicates.
Generally you'll get an error. Use a BIGINT if you are paranoid.
Yes it is possible: if you only allow for 2 digit numbers you can only have IDs up to 99, and so on. Inserts would fail once the limit was reached. It is a matter of common sense to choose an appropriate size.
Most database systems have a numeric datatype that can be wider than 32 bits. If you anticipate more than 2^32 records you should use an appropriate key width.
Oracle doesn't support autoincrementing ID columns and standard practice is to use a sequence generator. A sequence generates integers of up to 28 digits, so if you run out of those then ... I guess you have a pretty big table. But behaviour would then be dependent on the configuration of the sequence generator -- either an error or it would cycle back to the start value and you'd get a PK constraint violation on the next insert.