I maybe missing something here, but if you have the objects in VSS (Visual Source Safe) already then you should just be checking out the file version from VSS then editing it in SSMS then checking it back in. In fact, SSMS 2005 did a much better version of source control integration that in SQL Server 2000 toolset. You can even create solutions and project containers for your files. The way I currently do development of an object which is under VSS control is check it out from VSS, then open the file which contains the script. The SSMS interface will show the file name in the tab and should have a red checkmark indicating I have a checked out version of a file. (If I just did a "Get Latest Version" and didn't have it checked out it would have a padlock graphic on the right side of the tab.) After making my changes, I save the file then I check it back in through the VSS interface. If you have the files included in a project and solution, then you can just check them in and out from the SSMS interface. But, I have found when working on an individual file from source control I have to do the check-in/check-out from Visual SourceSafe.

One thing to be aware of when working with the database objects, as we know they are stored on the database, so if everyone isn't following the procedure of only editing the objects from the source control files it is possible that the file in source control may become out of sync with what is on the server. Another item to consider, the file is created the way you wrote it. For example, if you saved the file as a "CREATE PROCEDURE" the source control file will be saved as "CREATE PROCEDURE" which means you may have to include the "DROP PROCEDURE" statements in you file if you want to go that route or you just have the policy that the first change to a previously created procedure changes the file to an "ALTER PROCEDURE". So, as a development group you would have to decide on your development procedures. It does seem like you are doing duplicate work based on your initial explanation and if the 2000 instance is just for the generate script functionality then you can get rid of that part of the process.

Another consideration as mentioned by an earlier post is Visual Studio Team System Database Edition. It is more expensive solution but it is supposed to be a development suite for the Database Developers. The company I work for has purchased it recently and I am on a team to roll it out to our developers so I am still learning it myself. The software supposedly handles the building of the proper scripts for making changes to database objects. For instance, if an object already exists, it will use an ALTER statement rather than a CREATE statement. It has tools that compare the schemas between your changes and what exists currently. It also provides data generation tools and unit testing. But as I said, I'm still learning how to use the toolset and determining how they fit into our development environment. Here is the link to the blog of new DataDude from Microsoft: DataDude

I hope that helps.