Unfortunately Paul has not (yet) provided details on where in the manuals he found the statement: "In destination server DBID slot should be free" (and I'm too lazy to go do a brute force seaerch), so I can't be 100% sure what dbid issue he's referring to; but from my perusal of the 'mount' command I'm about 98% sure he's referring to the issue of the 'wrong' dbid referenced in his allocation pages after mounting to a different dataserver.
Assuming Paul is referring to the allocation pages having the 'wrong' dbid ... your 'approach' has nothing to do with the issue raised by Paul.
--------- db move/copy method
A - Paul is moving a database between dataservers using the unmount/OS-level-copy-of-db-devices/mount method.
B - Paul is *not* using a 'dump/load database' method.
--------- the issue
A - The OS-level copy (cp/scp/rcp/ftp) has no concept of an allocation page let alone how to update the dbid value stored in allocation pages; the OS-level copy is just performing a raw copy of the sybase device(s); net result is that upon attempting to online the database in the new dataserver, an error will occur when the dataserver processes the newly mounted allocation pages and finds said allocation pages reference a dbid that's already assigned to some other database.
B - If he was using a 'dump/load database' method then he would not be running into this particular issue since one of the benefits of the 'load database' command is the fact that the allocation pages in the newly loaded database will be updated to reference the correct dbid value.
--------- the fix
A - Prior to onlining a database we need a means of updating the allocation pages (of the newly mounted, but not yet onlined database) with the correct dbid; from the documentation on the 'mount' command (see my previous post- above) it appears the 'dbcc checkalloc' command is what we're looking for, and this would make sense in that we're trying to fix an allocation page issue; unfortunately the documentation isn't as clear as it could be on this topic (eg, maybe the docs should say something like: "after mounting a database, run dbcc checkalloc/fix to ensure allocation pages are updated with the correct dbid, then online the database" ... ?)
B - If using the 'dump/load database' command, this issue shouldn't arise so there should be no need to update the allocation pages with a new dbid.
--------- confirmation
A - I haven't tested this solution (yeah, I'm lazy), but Juergen has already posted that this is exactly what he's had to do in the past (ie, mount, dbcc checkalloc, online); should be easy enough for Paul to run his own test to verify/negate this solution.
B - I don't see anything in your approach that addresses how to update allocation pages with the 'correct' dbid (assuming Paul wishes to continue using the mount/unmount solution); in fact, one part of your approach ... update sysdatabases set dbid = <somebignumber> ... will likely introduce corruption into the database if simply because this 'update' will not update the db's allocation pages with the new dbid = <somebignumber>.
--------- once Paul's got his db mounted on the new dataserver ...
Paul will *then* need to address any cross database reference issues, eg ...
sysusers/sysroles <--> master..syssrvroles
sysusers/sysalternates <--> master..syslogins
proxies <--> master..sysattributes/sysservers
syscolumns.encr* <--> key db (column level encryption)
sysreferences <--> other_db..sysobjects (cross db RI constraints)
procs/triggers/views/SQL-code that have references to other dbs
... but then these are concerns whenever bringing a database up in a different dataserver regardless of how the database was copied.