Not the worst idea for students to learn to communicate in the open, which is a hard requirement for OSS contributions. Also the more proactive students would in any case be doing this. And making things a bit more realistic motivates people as well. For people worried about an influx of low quality PRs on their projects, you have the right to reject bad PRs and you can also help out newbies with nice labels as "good…
I certainly do, but I'm worried about the signal to noise ratio on PRs sinking through the floor. After all, it's not as if the difference between a good PR and a bad PR is magically known to me before I open it and read the patch. The maintainer has to spend a certain amount of time to see if the PR is any good, and if there are a hundred PRs more than usual, then the maintainer going to be much more likely to mass-reject all the PRs from a given institution, regardless of how good they are.
We've seen exactly this situation with Huawei and the Linux Kernel, where the kernel maintainers threatened to reject all patches from Huawei because it became apparent that engineers at Huawei were optimizing for the number of patches in the kernel, rather than quality of patches. In the same manner, if a university mandates that a student must have at least one patch to an open-source project in order to graduate, then there is a rather large population of students who will spray patches at every open source project available to them until one of them happens to accept their patch, intentionally or not.
Now, that said, I'm not opposed to the idea. Writing patches to an open-source application could be good as part of a larger project. Have the student pick out an open source project (it doesn't have to be big) and write up a report about the architecture used, the reasoning behind the design, and what issues they see. Then, as part of that process, have them write a patch against the project. This patch should be reviewed by the instructor, and should be graded on its own merits. Then the student should submit the patch to the project. At that point, while acceptance of the patch would certainly be nice, the professor should have enough data about the student's ability to evaluate an existing software project and make a meaningful contribution to it to grade the student even if the patch is not accepted by the time the semester ends.