So, automatically killing long running queries or queries that are blocking is a very bad idea. Can it be done? Certainly. There are a number of ways you could do it. I strongly recommend against it though. For example, backups are frequently the longest running queries on most systems, yet, killing them would be a very poor choice. So, we need to start building in exceptions to our "kill the slow query" methodology.
Second, if you're the person who has submitted Query X, and this is that awful query that runs for a long time, holds lots of locks and blocks off people, what do you do after the system kills your query? I seriously doubt you reexamine your T-SQL code and start a tuning session to ensure you don't get killed again. Nope. You just resubmit it. Three or four times. Then you call the boss, who calls your boss, who complains that their person can't get their work done, so stop killing their heinous query even though it's bringing the server down. Now, you are in a situation where you now can't touch that query. This will happen to you a lot.
Instead, you need to do the hard work of identifying the queries that are causing pain, and then, not killing them (resulting in rollbacks, retries, calls between bosses), but tuning them. You need to work with the people submitting the queries and find ways to filter them appropriately, index them, etc., Whatever you have to do.
I'm not an expert in SentryOne (in fact, I work for the competition). I'm sure they have a long running process report (or reports) and you can then identify the painful queries. Further, I'm pretty sure they have a whole set of tools around query tuning (I know because I've worked with some of them their employees). Use those tools to identify and address the issues. If SentryOne can't help on this (and I'd be very surprised by that), then you can always fall back to using extended events to capture query metrics yourself to identify the painful queries.