It isn't possible to restrict TempDB use in the way you want, other than time-to-execute limits and simply blocking it completely, as already suggested.
If it is possible to separate the sort of queries that might produce this pattern, either because you control the application and can give it a little smarts in this regard or people are using other tools to log more directly into the database, then you could run potentially nasty reports against a replica/mirror/other instead of the main database. This would at least stop the problematical queries impacting the main application.
There is nothing to stop this reporting instance being on the same server(s), but it will want to be in its own SQL Server instance at least so it doesn't share TempDB with the main application DBs. The "extra" TempDB can have its own growth limits and perhaps be on different drives (or a different IOPs pool if using a SAN arrangement for storage) and you can artificially limit the CPU and memory use of the new instance too (to give the main app(s) priority) if they share resources. The main gotcha with this idea, aside from the extra admin, is it will have licensing implications unless your data is small enough to fit in express edition's limits (which I think unlikely if it is big enough for this issue to regularly be a problem for you) so might not be a practical option for that reason.
You might still want to impose other limits even on this reporting instance, to stop really nasty queries blocking the simply just-a-bit-nasty ones or pulling the copy down so hard that effort is required to bring it back into sync later.
As an aside on the other suggestions: When blocking TempDB access to stop temporary tables being created, be careful of "clever" users writing ad-hoc SQL who will potentially do worse things than they are right now to work around that limit!