Or more generally: to trigger compiler errors in test projects if something that can be checked at compile time is wrong?
In principle, why not. A failed test is a failed test regardless of whether it happens at compile time or runtime. Compile time failures can also occur without an explicit static assertion.
On the other hand, if your unit tests are only executed infrequently (shame on you), say every few dozen check-ins, then a compile time check might hinder you in finding out if there are more breakages. That depends on your build structure and how your tests are organised.
Yes, it is okay to use static/compile-time assertions in unit tests
In my experience, many developers don't the unit tests enough, although they may compile them. In a complex environment, it is not necessarily possible to run the unit tests on the build machine (environment setup, etc) but you could certainly compile the unit tests. Static assertions would find problems at that point regardless of whether they got run at all.
Also, we've found that it is less intrusive to add the unit tests to the list of objects that need compiling compared to forcing people to compile-then-run a unit test runner before you let them compile/package the main code. Your mileage may vary, of course.