Estimating at Sprint Planning

When do you estimate? And what?

We estimate stories using Gnome Days, which becomes the story's initial "Story Point" value. I know Scrum teaches to estimate the story points as a relative complexity or size, not taking time into account.

So you have a bunch of stories in your backlog, all estimated using Gnome Days. Meaning, I have knowledge about the size of the stories in the backlog, and with my knowledge about previous actual velocity I can derive an estimate of how long those stories will actually take.

So I go to the Sprint Planning meeting with a bunch of stories, the top priority stories in the backlog. The team picks a bunch that they feel comfortable with.

Now, how much do they look at the story point values when they pick what they commit to? Do they even care about it? At this point? Or do they adjust completely to it in relation to knowledge about past velocity? We do something in between. The team picks a set of stories they feel comfortable with but use the story point sum to compare against past velocity, as a sanity check.

Next question: Do you estimate the un-estimated stories at the sprint planning or are you supposed to have that ready when you enter? If so; at what point do you estimate stories? Does the Product Owner estimate the stories himself? Or is it done by the whole team at some other point (other than the sprint planning)? Or do you have an "estimation team" that meet regularly to estimate the most important currently unestimated stories in the backlog?

The latter is my preferred approach, until someone gives me a good argument as to why not. I like the idea of a relatively stable team of mixed competences who estimate stories ahead of time, in priority order. That way, that is done when the team enters the sprint planning, and the team can focus on picking stories and instead revise the estimates, breakdown into tasks where needed and/or sanity-check the commitment. How do other organization do it?