T-SQL is a high level declarative language that generally doesn't involve a lot of branching (although every organization has a handful of 2,000+ liners). So, I'm guessing that Code Coverage in the context of T-SQL would be testing your code with the goal of insuring that the resulting execution plan(s) perform well under various data-set sizes and input parameters.

That's what I do when I'm Unit Testing a new stored procedure, sometimes creating a mockup datasets that are 10x the expected size of the data in production after one year, or auto-generating stored procedure calls using 1000 different variations of parameters.

Also, I'm thinking that a traditional Regression Test, perhaps something like a comprehensive test plan or replaying a production SQL trace in QA to simulate actual user activity, is one way to achieve Code Coverage for the SQL back-end of a database application.