I think one thing that might help guide this discussion and make reviewing your pull request easier is for you to write up a YTEP document that goes a little bit into the technical and social details behind this change. Things that would be good to hear about:
* What do future contributors need to do to add answer tests in the new framework?
* What are differences between nose and pytest and developers need to be aware of?
* Are there any downsides to making this change?
* Any technical details that might be helpful for reviewers of your pull request to read in a more narrative fashion than is possible in a pull request.
Writing up a YTEP is a great way to both document the change in a format that will be preserved long-term and a way for you to explain what's happening without others needing to read over all the code changes. It's also a good thing for your personal resume to be able to point to a design document for a major development push along with the code and pull request(s).
Separately from the YTEP, I'd like to encourage you to think about breaking up your pull request into multiple chunks that can be upstreamed one at a time. This might mean running both pytest and nose for a while as things get converted. I could imagine this going like, first pull request sets up the pytest infrastructure and gets pytest running but with no actual tests running under pytest. Second pull request converts some subsection of the code to run under pytest. Third pull request does another subsection and so on until the entire codebase is converted. That will probably make it much easier for reviewers to understand your changes and make it easier for reviewers to spot bugs and possible issues.
I understand the desire to upstream something like this all at once but I think there's a big concern about making big changes to the codebase that are difficult to review all at once.
Hope that's helpful, please feel free to ping me on github if you want my help with anything.