Don't see how this approach would be all that useful. Having the database generate the sequential GUIDs is fine and keeping them in a queue on the .NET side is ok. The problems you're going to hit are protecting access to the queue, ensuring that an entry isn't reused, knowing how many GUIDs to create initially and each time the queue becomes emtpy, not to mention taking a database hit each time you need to refill the queue.
Yes, but there are other ways to do this where you can create a sequential GUID locally on the application side which uses the same logic as used by SQL Server.
If I understand what you're asking, you can create a complete C# class which mimics everything about a normal Guid but changes the implementation so that it uses the same logic used by SQL Server to generate the actual Guid values.
Needing sync would largely depend on the application, but if you use SQL Server to create a pool of sequential Guids that are queued by the application, every so often you will need to go back to that pool and generate a new group.
Needing sync would largely depend on the application, but if you use SQL Server to create a pool of sequential Guids that are queued by the application, every so often you will need to go back to that pool and generate a new group.