Does UPDLOCK guarantee concurrency
Short Answer
The update lock is sufficient, but you can achieve what you want more simply with:
UPDATE dbo.tblOrderNumber WITH (SERIALIZABLE)
SET @NextOrderNumber = NextOrderNumber,
    NextOrderNumber = NextOrderNumber + 1
WHERE CustomerID = @CustomerID;

The WITH (SERIALIZABLE) hint is not strictly required if there is a unique index on CustomerID.
Longer Answer
The update lock hint is sufficient in the code provided. Only one transaction can obtain an update (U) lock on a resource at a time, and update locks are held to the end of the transaction. The update lock is converted to an exclusive (X) lock just before the change is made. The exclusive lock is also held to the end of the transaction.
Taking an update lock when reading therefore provides the concurrency guarantees you are looking for. To be clear: Once the update lock is acquired (by the select), no other transaction can acquire an update lock on the same resource until the first transaction has committed or aborted.
You could also run the transaction (or single update statement) at the SERIALIZABLE isolation level without hints. After all, the guarantee you are looking for is that the transaction should execute according to a serializable schedule. If you are uncomfortable relying on knowledge of locking internals, specifying the desired isolation level, and letting SQL Server handle the details, is probably simpler.
Obviously you would need code to handle errors or possible deadlocks as well. I assume you omitted this from your example. A belt-and-braces approach would also SET XACT_ABORT ON for the procedure to ensure almost all possible errors will abort the transaction instead of silently continuing.
It would also be possible to write a robust locking implementation manually using application locks (with sp_getapplock and sp_releaseapplock), but in all honesty using the built-in serializable isolation level is probably simplest.
For more information, see my series of articles:

SQL Server Isolation Levels