What you propose is basically the opposite of what has been done a few times in the past, which in your terminology could be called post-upgrade steps.
The two examples I am thinking of are:
- The question enging changes in Moodle 2.1. Here, there was a long, complex upgrade of all the data about all quiz attempts ever. There was an option to not do all of the upgrade duing the main maintenance mode window. Instead, the attempte could be upgraded a bit at a time on cron aftewards (and there was code so that if you tried on access a quiz attempt were the data was not yet upgraded, you got an error saying to try again later).
- The new mod_assign, replacing mod_assignment. Here, the new feature was implemented as a new activity, with a conversion tool that could be run at any time. Of course, both had to be maintained for some Moodle versions, before conversion was made a compulsory pre-requisite in the Moodle release where the old assignment was removed.
The advantage of doing it this was is that rather than having to install the upgrade code into the pre-upgrade Moodle, it can instead be developed and tested alongside the new functionality, and all the code gets deployed at the same time, as part of the upgrade.