I don't know that I would recommend your approach. If you have an existing SQL 2012 machine then why would you upgrade to SQL 2014 instead of just jumping to 2019? You're going to have to retest your database anyway. Granted there is a slightly higher chance that 2019 breaks something over 2014 but at some point you're going to run into that anyway. It doesn't seem like a good idea to double test, especially if you plan to upgrade to 2019 shortly thereafter.
Note that your existing DB, when restored/attached to SQL 2014 (or 2019) will remain on the compatibility level it is now. So once you are on the new SQL version your DB will still be at 110 compatibility level (the level of SQL 2012). It is a separate step to "upgrade" your DB to the current level and one you'll need to do at some point. This will help reduce the likelihood of an upgrade issue. In my experience data teams will drop the DB onto the newest version of SQL and do some testing to make sure it works correctly. If it does then the old SQL server can go away. Then you bump up the compatibility level of the DB to (ideally) the latest version and verify everything still works. If it doesn't then backtrack on the compatibility level until you can identify and fix the issue.
As for downgrade rights, it depends on how you got your SQL license. If you got Software Assurance or volume licensing then you do have downgrade rights. I don't know about retail licenses. But from my understanding it is only for 2 versions back. Therefore your SQL 2019 license could be downgraded to SQL 2017 or SQL 2016. SQL 2014 is too far back. If you wanted to go the route you originally proposed you'd either have to get SQL 2017 licenses and then buy SQL 2019 licenses later when you're ready or buy SQL 2019 licenses but install SQL 2016.