Interesting question! I’d say forking is probably fine but there’s some gotchas that may come up in future if it’s done that way.
Forks are really intended to push changes from the fork to the upstream repository, not the other way around. They share the same history so they can pull in changes from the upstream original at any time. However the nature of forks themselves leaves them linked with the original repository even when the projects may diverge.
You can only have one fork of a repository hosted under a single account, so if a team/org/user/whatever wanted to create a second project from the same base you wouldn’t be able to.
Forks—especially private ones—are also a bit of a permission nightmare. Private forks are still technically “owned” by the account that owns the upstream original, meaning that if the original is deleted then all forks will be deleted too. I don’t believe it’s possible now for an organisation to fork a private repository, but this can still come into play with repositories from specific accounts. (In the case of public forks they are simply detached, not deleted)
Because of the intended use case of forks in this situation I’d probably recommend cloning the repositories, not forking them. As they share the same history you should easily be able to pull in changes from the upstream original by adding it as a secondary remote in the same way you’d update a fork:
There’s also repository templates that sounds ideal for what you’re doing with your repos. This allows someone to create a one-click copy of a repository under their own account/org/whatever. I’d highly recommend you check it out as it sounds like it’ll solve exactly this problem: