What I'm going to write here is not best practice, because if anything usable security research has shown, it's that the best practice (e.g. NIST guidelines) is seriously lagging behind on research. This is a condensate of research done on the topic, my own discussions with usable security experts at UCL, and my own approach as an interaction designer.
Take the question in reverse: what are the security requirements for your website, and what are the authentication requirements?
Security
For most websites, this boils down to one simple question: what irreversible externalities will the users (the users first, please. Then you as a provider) suffer if their account is stolen?
If users suffer serious consequences (e.g. financial losses, significant loss of reputation, identity usurpation with potential legal repercussions), then you care about them having a non-reused, strong password. Otherwise, you can let them reuse a password of their choice.
This determines whether you control the authentication factor, or they do. The intrinsic truth behind this rule is that users will reuse passwords simply because they have to cope with too many passwords to make a unique one for every website (see research on managing password portfolios).
Usability
Now it's time to talk about interaction modalities. What we're looking at here is to proportionalize the amount of user effort to the perceived benefit of using your website's services. Do users need to log in once a year to do some tax return or renew a subscription? Then, don't make them remember a strong password.
Do they need to log in on a regular basis to your service, and is automatic login not advisable (e.g. online banking or email)? Then, users might be more tolerant of learning a generated password. The key here is that users themselves must be convinced the perceived benefit of the service outweighs its perceived security cost, or they will disengage (see the Compliance Budget theory).
Low-effort strong authentication
What do we do when users cannot tolerate the effort requirement of a strong password? Let's now look at your own authentication requirements. The most glaring option here is to delegate authentication to a third party. This could be Facebook or Google, or a government-backed federated identity scheme for services with legal obligations to authenticate users in the real world.
You could also switch to authentication tokens, or add authentication factors to compensate for a potentially weak password. You could also go the route of one-time passwords sent via email. The solutions available depend on what restrictions you have with regard to alternate forms of authentication.
High-effort strong authentication
Remember to keep the perceived cost-to-benefit ratio of your authentication scheme balanced over time.
Don't be the kind of moron who imposes a unique, super-complex password onto their users only to force them to change it every 3 months, unless your threat model really justifies it. This is a sure way of getting users to store their passwords. And with users logging in onto services via their computer, mobile, office computer, etc., not all of them will use a reputable password manager (notwithstanding clipboard API attacks that threaten a wide variety of use cases for password manager users both on mobile and desktop).
You can also act on the perceived benefit and cost by communicating to your users what they gain from using a unique password and why it's important to do so specifically for your service. You should, in return, commit to good security practice and to respecting your users' time by not forcing additional security theater onto them. If they respect your decision, they will be less prone to bypassing your security measure or switching to competitor services.
Low-security authentication
Just email them a password reset link, let them do what they want, sit back and relax! Or switch to Google/Facebook authentication anyway because it's still more secure and usable than password authentication.
