SQL Server T-SQL Parser in .NET to check syntax and object existence

My question is, what would the possible implications be to execute statements as describes in a transaction and then roll it back

The main issue there is that not everything can be rolled back. If the scripts are using things like xp_cmdshell, expect pain. But that kinda goes with the territory.

A better alternative to a transaction is: FMTONLY. This is kinda similar, but rather than do work and then undo it, it simply short-circuits everything that would involve rows. This means that it has no IO cost, no rollback cost, and won't cause blocking. It does, however, suffer from the same issues re things like xp_cmdshell. Additionally, note that MSDN has the caveat:

Do not use this feature. This feature has been replaced by sp_describe_first_result_set (Transact-SQL), sp_describe_undeclared_parameters (Transact-SQL), sys.dm_exec_describe_first_result_set (Transact-SQL), and sys.dm_exec_describe_first_result_set_for_object (Transact-SQL).

Unfortunately, as the names suggest: these only work for the first result set. If we take your [INFORMATION_SCHEMA].[TABLE] example from the comments, and try that with SQL-Server's suggested option:

EXEC sp_describe_first_result_set N'
SELECT * FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLE_NAME] = ''MasterCurrencyConversions'';
SELECT * FROM [INFORMATION_SCHEMA].[TABLE] WHERE [TABLE_NAME] = ''MasterCurrencyConversion'';
SELECT * FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLE_NAME] = ''MasterCurrencyConversions'';
';

then it works, returning:

is_hidden column_ordinal name            
--------- -------------- ----------------(snipped)
0         1              TABLE_CATALOG   
0         2              TABLE_SCHEMA    
0         3              TABLE_NAME      
0         4              TABLE_TYPE      

etc - it does not tell us about the problem in the second SELECT, because it stopped at the first. Conversely, using the now-deprecated FMTONLY option:

SET FMTONLY ON;
SELECT * FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLE_NAME] = 'MasterCurrencyConversions';
SELECT * FROM [INFORMATION_SCHEMA].[TABLE] WHERE [TABLE_NAME] = 'MasterCurrencyConversion';
SELECT * FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLE_NAME] = 'MasterCurrencyConversions';
SET FMTONLY OFF;

Gives us:

TABLE_CATALOG                                          
---------------------------------------------(snipped)

(0 row(s) affected)

Msg 208, Level 16, State 1, Line 3
Invalid object name 'INFORMATION_SCHEMA.TABLE'.

So we get our error, but we're using an officially "do not use" feature :(

Additionally, note that it doesn't execute DDL commands; this means that otherwise valid operations can fail - for example, here @Foo is fine but #Bar fails:

SET FMTONLY ON;
DECLARE @Foo TABLE (id int not null identity(1,1))
SELECT * FROM @Foo
CREATE TABLE #Bar (id int not null identity(1,1))
SELECT * FROM #Bar
SET FMTONLY OFF;

which outputs:

id
-----------

(0 row(s) affected)

Msg 208, Level 16, State 0, Line 11
Invalid object name '#Bar'.