Is this a simplified version of a much larger problem where the values in Table2 need to be pre-generated?

The reason I ask is because you're re-inventing the wheel called IDENTITY() and I'm not understanding why you'd want to do that. The new SEQUENCE would also perform a similar idea and allow you to grab ranges as long as you're in 2012+.

http://msdn.microsoft.com/en-us/library/ff878091(v=sql.110).aspx

Can you help us understand the need for this?

However, I wouldn't approach this directly the way you are. I'd use a one to one relationship off the surrogate key in your table1 (the identity or whatever), and then assign that to a field in table2 to make sure that you don't end up with concurrency issues.

The reason I'd go that way instead of bringing the key to table1 is because it's less data passes, thus reducing the chance for concurrent pickup by multiple users. By forcing the update to occur on the table you need to make sure doesn't duplicate, and you are doing this as the rows insert into table1, multiple inserts can't update the same row, but they could have read the same row and wrote the user in with duplicated #s.