I've thought about this a bit and I don't believe there is a way you could do it without some level of custom dialplan. The disconnect with sending the call to an outbound route destination is that you 'lose' the number being dialed once it goes back into the standard call flow. This is because the number is retained within the ${EXTEN} and a result of the final destination, it gets vectored with a new Goto() call. One would have to examine the call to see if it's maybe still retained in a channel variable somewhere such that you had the option of going to a CallFlow destination or something similar, and having that destination have the potential of going to some small custom context which gets it back into a normal outbound flow.
As mentioned, the TimeGroups don't help because those specifically act based on time, they are not linked to an actual time condition which would otherwise let you use the TimeCondition's feature codes to toggle it.
No matter how you cut it, I think you're going to need some custom dialplan to address your desired outcome. You are welcome to submit a feature request for consideration into a future release to address something like this.
One thought, a little convoluted, with 'minimal' custom dialplan, could be as follows. You have the call go to a custom trunk. That custom trunk sends it back down the local channel into the 'ext-did' context with a unique prepend. Such as 999999${EXTEN} where ${EXTEN} is the number that was dialed. You create an inbound route for 999999XX. which catches those numbers dialed and send that to your call flow control. The destination route for that call flow control becomes a custom context you have to create. You can register that with the Destination Registry so you can configure it from the GUI as a destination. That destination would simply take the number out of ${FROMDID} where it has been stored by the inbound route, strip off the 999999, do what ever else it needs to do so as to now send the call out a normal outbound route. You may have to get creative such as send the call to a specific route that is normally not made available to callers (using Extension Routing) or something similar. There are a lot of considerations in doing something like this including 'ugly' CDR's and questions of what you're expecting for CID's on outbound calls, etc.
Of course if you're going to go through all this, you can also just send it to a custom trunk that has slightly more sophisticated dialplan and does what you need. It can take advantage of an existing state of a Call Flow implementation but not bother with the complexity of going back into the 'normal' dialplan and just handling the routing directly from there.