Sizing Product Backlog

What would be the value of sufficient detail that would allow Developers to estimate so many Product Backlog Items, much less go through the estimation process?

Refining too much of the backlog, whether that involves estimation or not, is wasteful. What you learn by doing the work and getting feedback from key stakeholders will almost certainly change the Product Backlog. Not only is the order likely to change, but you may find that some PBIs are unnecessary and others were missed. If you invest too much time in refining PBIs and then end up changing or removing them, that time is wasted.

When a product owner creates an initial backlog before the first Sprint, do all Product Backlog Items need to be assigned with Story points already or can story points be assigned gradually throughout the project?

Think of it the other way around. In Scrum there is no excuse for putting the establishment of empiricism in delay. We want to start sprinting now. As long as you have enough of a Product Goal and a modicum of a Product Backlog, all else can emerge later.

The Developers need to know enough about a set of items to determine if they feel comfortable pulling them into a Sprint Backlog.  That need never changes whether it is the first or the fiftieth Sprint.  However, trying to become that familiar with every item in the Product Backlog is a wasted effort.  As @Thomas points out, it is not uncommon for things to change order or for items to become unnecessary.  The Product Owner will be better serving the Scrum Team by keeping the items that are in the Product Backlog ordered so that the Developers will know to become familiar with the items closest to the top as they are the ones that will most likely need to be pulled into a Sprint.