Hmm, the docs seem to say that:

All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database. For example, suppose a Visualforce page called an Apex controller, which in turn called an additional Apex class. Only when all the Apex code has finished running and the Visualforce page has finished running, are the changes committed to the database. If the request does not complete successfully, all database changes are rolled back.

So for certain definitions of delimited by...class method a single method that inserts against a utility table containing just an autonumber name that is then deleted at the end of the method before returning its name value should provide you with a valid numeric nickname with zero rows used at the cost of 3 DML operations: one insert, one query and one delete.

Alternatively you could schedule apex job at crazy o'clock that deletes all save one max(name) row, saving you one Delete DML statement.

If you wanted to get crazy about it.

Hmm, the docs seem to say that:

All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database.

So for certain definitions of delimited by...class method a single method that inserts against a utility table containing just an autonumber name that is then deleted at the end of the method before returning its name value should provide you with a valid numeric nickname with zero rows used at the cost of 3 DML operations: one insert, one query and one delete.

Alternatively you could schedule apex job at crazy o'clock that deletes all save one max(name) row, saving you one Delete DML statement.

If you wanted to get crazy about it.