Generally speaking, pointing a new database instance (or instances) is a "deal breaker" when it comes to the farm. My "fallback safe opinion" tracks with the general consensus: construct a new farm (i.e., a new configuration database), build out your SSP, and then perform content database migrations into the new farm.
Here's a tip on avoiding this (painful) process in the future: implement SQL connection aliases. An article describing how to do this can be found here: http://decipherinfosys.wordpress.com/2007/11/26/using-a-server-alias-to-connect-to-sql-server-instances/. Aliases are also particularly helpful from a disaster recovery perspective, as they introduce a layer of abstraction between your farm and the supporting data layer.
I haven't tried this next item, so I mention it strictly as an investigative point ... but you might be able to implement aliases in your MOSS environment now before you do a rebuild and potentially avoid it altogether. Let's say your SQL Server is named "SQLSERVER" and you'll be going to a named instance on that server called "MOSS". For each MOSS server:
- Install SQL Client Tools
- Establish an alias named "SQLSERVER" that points to the server "SQLSERVER"
- Build out your named instance (SQLSERVER\MOSS) and copy over all databases for the farm to the new named instance
- Switch the "SQLSERVER" alias on each MOSS server to point to "SQLSERVER\MOSS" instead of "SQLSERVER" and see what happens.
At worst, this will fail and you'll have to build out a new farm as you're expecting to do now. At best ... you'll continue to run without a farm rebuild.
I hope this helps!