Can GitHub's Pull Request model be used for implementing post approvals?
Yes, I do believe so.  To explain that I need to lay some groundwork on how I have implemented something similar, I have simplified the model in an attempt to make it as clear as possible.

Assumptions

I am making the assumption here that Jenkins, TeamCity or similar is being used as the CI/CD tool of choice. Additionally GitHub is being used and that there is a well-defined and appropriately controlled branching structure:



Configuration

In this example, GitHub is configured as follows:


The Black 'Master' branch can only be merged into using Pull Requests, direct commits are disallowed.
The Blue 'Development' branch can accept direct commits or merges; in practice, there may be additional restrictions on this branch.
The Red 'Hotfix' branch can accept direct commits and merges.
Required Status Checks are enabled in strict mode to prevent pull requests merging when the branch is failing the build.
If the Hotfix branch is ahead of Master then pull requests into Master will be blocked, either with the Status API or the Pre-Receive Hooks on GitHub Enterprise.


The CI/CD tools are configured as follows:


Builds from the Development branch cannot be deployed to production.
Builds from Master can be deployed to all environments.
Builds from Hotfix can be deployed to all environments.
Deployments from Hotfix will notify some non-development function, for example, the Change/Release team and ask them to perform the post-approval.


Notes

Master is protected as it represents the current state of production, to do this practically you may have another "Release" branch that deployments are made from and only when successful merge into the Master branch.

Key Points

The Blue Development branch is basically a free-for-all.  Hotfix is kind of a free-for-all but any deployments trigger a type of Break Glass by notifying a non-development function who will perform the post-approval and in the process will merge the change into Master.

It's essential merges into Master stop while Hotfix is ahead of Master to:


Prevent a deployment from Master overwriting the Hotfix, which could result in an regression.
Prevent a Hotfix sitting in the Hotfix branch languishing without being merged in.


In some organisations it may help to prevent all pushes to the central GitHub repository while a Hotfix is pending post-approval.