Agile / SCRUM Course Structure: Downsides? Resources?
Don't subvert the very purpose and essence of agile development: the ability of the product owner to re-target the project (almost) instantly and make changes and adjustments to the backlog as business conditions dictate. The alternative of specifying everything at the start has failed repeatedly in long running projects in which it makes no sense whatever to follow the initial plan. 

Some of what I write below assumes you (or a future reader) is familiar with the terminology and the purpose of the various roles and tasks. To try to be complete would require a text-book. 

So....

You need to separate the developer group (Devs) from the product owner (PO) (person or group). I normally do this randomly, but other things might work. The PO has control of the backlog and releases features from it per iteration. The developers don't see the whole thing other than in overview form at the start. If you don't want the Devs to do estimation you aren't doing agile, so they should do that, per iteration for the most currently relevant cards (features). Then they give the PO a "velocity" that will determine how many features can be in the iteration. If you are doing a project in one term, iterations should be short (1 week?) and small. But even if they don't estimate time per task, having been pre-determined, then they should still give velocity, having seen a few of the features desired now. Otherwise they will just be frustrated by too much work in too little time. That leads to burnout and is not agile. 

The downside is that the PO doesn't get to develop. That may be an advantage depending on the makeup of your student group, or not. I prefer to be the PO myself so that I can throw in a kink or two along the way. 

As ctrl-alt-delor says, you need to prevent speculative, build-ahead, development. You have to be fierce in rejecting all attempts at it. Not showing the entire backlog helps with this, but simply rejecting any feature produced speculatively is needed. The problem is that your students have likely gotten in to one bad habit. They have probably in the past been given partly specified projects and assignments where "creativity" is valued. So they try to get creative, by their own definition, ignoring the needs of the PO. In the real world it seldom works that way (Startups excepted) and you need to learn to work to someone else's vision not your own. So you need to make that work in the class. 

The following is speculative and I haven't tried it. If you really want every student to experience every role then do this: Appoint a PO somehow for the first iteration and they hold that role throughout. Accepting or rejecting (with your guidance) backlog items as they are "completed." Then at the end of the iteration rotate roles so that the old PO becomes a developer and some other student takes on the PO role. They will need some time to become familiar with the backlog, however, so it probably can't happen that the iteration ends one day and a new PO takes over and specifies the next iteration immediately. A negative aspect of this is that the old PO will have knowledge they shouldn't have (and wouldn't have) in reality which may make them eager to speculate. 

I would also require the "small-ball" skills (sorry, US baseball term) that Extreme Programming suggests. I.e. personal skills: pairing, test first, etc. Pairing will help them teach one another and build team skills. 

Another possibility for doing a course on Agile Development, though it doesn't match your stated requirements is as follows. (I say this as others may benefit). Instead of one large project have a bunch of tiny projects with 10 minute features and 30 minute iterations. If you run a course in 3 hour segments this can be made to work. In fact, I know of one real-world outfit that does this sort of thing on real (i.e. large) projects - maybe one hour iterations.  With such a scheme a person is PO for one project but will take a different role the next day. 

At some point in any agile course, trying to be realistic, you need to throw a curve-ball (sorry). Change the backlog/project-direction in some fundamental way. Estimate from the current code-base and move on as usual. It really happens that way (experience here) and also shows that the word "agile" actually means something. Trying to make the initial requirements too precise is also a problem/trap  that will encourage speculation. Real agile projects don't work that way. The initial backlog is pretty vague about specifications. It is only as you approach the iteration in which a feature appears that it becomes specific. 

You will need to guide the PO so that they do sensible things. You will probably need to be the project Coach. If you need to ease the development you could provide some of the tests (unit tests) to guide the developers. After doing this initially they can take over. But you need to give them advice (as coach) on the quality of their tests.  

Note that I've merged ideas from both Scrum and XP here. Scrum works well for the overall management (Backlogs, acceptance...) and XP for the day to day tasks (pairing, testing...). If you don't require day-to-day level skills the students will probably just thrash. Agile requires discipline, which is often missed - especially by those who reject it. 

There is more to say, of course. But the bottom line is that to teach agile you need to be agile.