I believe the practice of top-down password assignment is (or was) common in military deployments.
Typically, you would estimate the average time to for a password being lost, though any number of means, some of which might include:
- Social Engineering
- Brute Force
- Careless Users Leaking Them
You would then take this estimate and force passwords to be re-generated in a "safe" time window. Your end users may hate you for this. It does however have many benefits:
- You can more easily link a password to an end user -- you generated them for everyone, so why was Bob using Alice's password when Bob has been given a password.
- The organisation can explicitly balance the risk of their passwords against their end user's convenience, specifically by varying the password's length and lifetime accordingly.
- Different systems can require different passwords for the same user, leading to easier-to-implement access controls, and better separation of concerns. However, you could just delegate authentication & authorisation to a specific identity provider for the same benefits.
However, you also need to be able to deliver the passwords to the users in a secure fashion. This is surprisingly difficult; you certainly can't email them over the open internet, a courier might be bribed (and can perform a DoS by being slow or "losing" the keys to the local river), and so on.
This scheme will also probably lead, as noted by The Bear to extremely hostile users. Hostile users are a serious security risk. They may stop using the system to do their job, by taking the data out of the (secure) application to work with it, which defeats the point of the system entirely.
All in all, for most applications, you're not guarding sensitive enough data to warrant this level of paranoia. You can't guarantee secure delivery of the passwords, you can't train your users, and you probably can't compel them to use your system. This is almost certainly a horrible scheme for 99.9999% of applications.