I would be hesitant to discard Waterfall across the board so quickly.
Although it is a flawed model for actually building software systems, it's not a bad teaching model to instruct on good practices for each stage of the lifecycle. Regardless of the process model that you apply to the project, you still perform requirements engineering, system architecture and design, implementation, testing, release, and maintenance (including refactoring and enhancement). The difference is how these phases are organized and conducted, but all of the activities still happen.
I'd argue that your transition from Waterfall to Scrum in the middle of the project is not the best idea. A key to Scrum's success is a long-running project. The first three to five sprints are the team settling in on a velocity, learning the process, and going through team development. Although you are doing through the motions, it's not really Scrum at that point. In addition, trying to create an exclusively Scrum-based curriculum is probably a bad idea as Scrum as not a silver bullet - it's better to teach best practices rather than a single methodology. In the workforce, not all projects are going to use Scrum. In fact, in some environments, Scrum would be detrimental to the success of the project.
You've already found problems with Scrum in an academic setting, and some of them are hard to adequately address.
The non-issue in your list of incompatibilities is that estimating is difficult. Yes, it is. But the only way to get better at estimating is to estimate and compare actuals against estimates. Students should be estimating size, time, and effort using various means (story points, source lines of code, hours, pages, person-hours) early so that they are more prepared to do so after graduating and entering the workforce.
The need for documentation is something that can be addressed from both the perspective of the professor and the perspective of the students. The Lean approaches tell us that documentation that doesn't add value to either the team or the customer is wasteful (in terms of time and cost). However, some documentation is needed to achieve some objectives of both the students and the professor (the customer/client) for various purposes. Overall, it sounds like an opportunity to teach process tailoring and quantitative project management (which does have a role even in agile methods).
With respect to Scrum meetings and scheduling, there are two ideas that come to my mind. The first is that this indicates that Scrum might not be the best process to use in an academic setting. There is no singular "best process model" for software projects, with factors such as schedule, staffing, visibility, and experience of the development team (among others).
Overall, I'd suggest emphasizing good practices, process tailoring, and process improvement over single methodologies. This will let you be the most effective to everyone taking the courses, and expose them to a variety of process methodologies and understand what the best practices are for a given set of conditions.
Since you're working to build a university curriculum, I'll give a high level overview of how the software engineering curriculum at the university I attended fit together.
The was an introductory software engineering went through the project in a waterfall model, with the lectures during each phase corresponding to different ways to conduct the activities of that phase. The teams progressed through the phases at the same rate. Having those clearly defined boundaries made fit well into the teaching model for a group of people with no to minimal experience working on teams to build software. Throughout the course, references were made to other methodologies - various agile methods (Scrum, XP), Rational Unified Process, Spiral Model - with regards to how their advantages and disadvantages.
In terms of the activities, there were specific courses to discuss requirements engineering, architecture and design (two courses - one focusing on detailed design using object-oriented methods and one focusing on system architecture), a number of courses focusing on designing and implementing various classes of systems (real-time and embedded systems, enterprise systems, concurrent systems, distributed systems, and so on), and software testing.
There are also three courses dedicated to software process. Software Engineering Process and Project Management that focuses on best practices for managing a software project with respect to multiple methodologies. A second process course teaches measurements, metrics, and process improvement (emphasizing CMMI, Six Sigma, and Lean). Finally, there's a process course that teaches agile software development (Scrum, Extreme Programming, Crystal, DSDM discussed) using a project carried out using the Scrum methodology.
The capstone project was a two-quarter project that was performed for a sponsoring company and run entirely by the student project team, with guidance from both the sponsors and a faculty advisor. Every aspect of how to conduct the project is up to the students, within any constraints set forth by the sponsors. The only university-mandated deadlines were an interim presentation half way (10 weeks) into the project, a final presentation at the end, and a quad poster presentation shortly before the end. Everything else was up to the sponsor and team to agree to.