This (general) approach is used in several AAA engines, but isn't very compatible with the way current Unity (2017) works.
To do what you've described, you'd have to build your own task system that doesn't immediately conflict with Unity's own process. Doing so is generally ineffective as the extra overhead negates the benefits of extra time.
For further knowledge, I suggest reading up on the fiber architecture. There are several great GDC talks on it, though they are currently locked behind the vault.
Here are the slides for Christian Gyrlin's GDC presentation on Naughty Dog's engine architecture. It can get a little low level, but it goes over how this kind of process can be achieved.
That's all well and good, but what if you still want to build it?
While there's no good way to do exactly what you want (specifically, timed processing in unity), there are plenty of ways to split your tasks into chunks, assuming the right data architecture.
So how do you build that data architecture? Well you need these metrics (Not comprehensive, hopefully a good start)
- Task Intensity : You need to know how much time / resources will the task requires.
- Order of Operations : Clearly defined task prerequisites and dependencies. These help you determine how to allocate your current resources. Small tasks with lots of dependencies should get high priorities.
- Pausing : Similar to above, when and where can a task sleep to free processing power for critical elements
- Granularity : The more granular your process, the easier it will be to take advantage of any left over resources.
Once you have these, it's pretty easy to grab something applicable using a job queue or query.
What's my preferred alternative?
Rather than intentionally calling tasks to use up leftover time, I recommend filling up that time with background processes / coroutines.
Coroutines are wonderful for dispatching tasks that don't need to be done same frame and are easy enough to split / pause. While not exactly the same context, I explain how to use them to split a task across multiple frames here
In general, if I'm at or above my target frame rate, I don't worry about squeezing out even more performance. Leave the buffer there for when future you wants to do something cool.
As DMGregory mentioned, Unity has plans to implement a proper Job System in the near future. If this is a feature you require, There is a unite talk on how it will work.