Does/can bucket system replace planning poker?

Yes - planning poker is not a required exercise in order to estimate items in the Product Backlog. 

That being said, it can be valuable in that it gives the team a way to include every member in estimating, helps create a clear understanding of what needs done, helps the team have some productive conflict, and allows for some fun in the process. I'd wouldn't be surprised to see some teams to grow out of poker and look for other more efficient ways of estimating. 

Does bucket planning still allow the team to collectively understand what needs done to complete a given story? 

I'm not familiar with the Bucket system so not sure if I can respond on it's applicability.  But I will say that Planning Poker is not part of Scrum.  It is something that a lot of teams have found helpful but there are many teams that have found it unhelpful.  The Scrum Guide only mentions estimates, not story points.  How ever your team finds it beneficial to do estimates and can become better at providing such estimates seems appropriate to me.  I once lead an exercise in estimating using fruit.  Different sized, different textures, different ways to use the fruit could all be considered in estimation.  I see no reason buckets can't be useful.  

When sizing the next batch/release of stories, I'm thinking its a good idea to have "reference stories", e.g. keep a representative 1 and a representative 20, so that the team can again, size with relation to the previous batch of stories.

Would these reference stories be using their original estimate or are you suggesting putting actual values after the fact based on the work done? And will these reference stories change over time as the team and product matures?Wouldn't the discovery encountered while doing the reference story influence the estimation of a future story that could be considered similar?  And if so, see the first question in this paragraph. 

I recommend not revisiting and changing an estimate to an actual for this purpose because that is a slippery slope to updating all the stories in your sprints to ensure that you get "credit" for all of the work actually done and story points become a measurement of success instead of using the value produced as the measurements. Estimates are guesses based on what you know at the time of making the estimate.  The beauty of Planning Poker is that it suggests you do the activity relative to what you know not based on something you have estimated in the past. I feel that each Product Backlog Item should stand alone and as such should be handled alone and not as a larger bundle.  The Backlog Ordering is done based on the definition of each story. Even related stories are not always ordered together. 

So, while buckets could be used as a sizing mechanism, such as t-shirt sizing, I don't advocate trying to lump many items together in general terms.  Inspect and adapt each item independent of each other. I have seen too many problems arise because "these are all the same" is used which leads to much less discussion, i.e. transparency, on the individual items.

Bucket system seems to work much nicer than planning poker

Is that the experience of your team? Has it significantly improved their ability to forecast how much work they can take on and deliver?