When estimating you can choose two paths: either try to cut stories to small easy-to-estimate development tasks or leave them as bigger wholes and try to rough-estimate their complexity.

Actually Scrum takes the latter. You don't even estimate in hours but in story points (at least most teams do). The clue of Scrum estimation is to become good at comparing complexity of stories. For the first sprint you just guess how many story points you can complete during iteration. Then, with each sprint you have more and more data to figure out real velocity.

With this approach estimation session doesn't have to take few days since you estimate fairly high level concepts. Usually the very first estimation in project will take more since Product Owner will need to describe much of general idea of a project to get people context of tasks which they'll be working on and the team doesn't have historical data to base on so they'll be asking much more than during later stages. With every next iteration people become more fluent with putting their estimates and discussions on differences lasts shorter. It's pretty often when whole team, after few iterations, during planning poker comes out with the same story points value.

Keep in mind that an estimate is just that: only an estimate.

When you start out, you may fall short of what you thought you could accomplish. Over time, you'll become better and better at it, particularly if you are working with the same product owner and team.

It is an iterative process. Don't get frustrated when reality doesn't match the estimate. Iterate, learn and improve.

We have 2 Week sprints, our Show & tell, Retrospective & Planning all take place on the same day, a Tuesday.

Our planning session is time boxed for 2 hours, but very often the teams have completed planning under this time. That wasn't always the case, but once they got into the swing of it got easier.

You don't really state exactly what it is about planning your finding so difficult about planning. The point of the stories is they are a 'promise for a conversation', the amount of detail you are talking about simply doesn't exist on them and shouldn't, stories should be expressed in terms of business value, they certainly shouldn't have any 'design' on them. There should be a well defined set of acceptance criteria on them to tell you what the completed story looks like, but not how it's done. Story's are the What & Why.. not the How

In our planning sessions, we always earmark the likely stories for the next iteration, this allows our BA/QA combo to come up with acceptance tests (for TDD), these acceptance tests are our 'spec' during the sprint (in readiness for the next one). The devs will work on writing automated tests & code to pass the acceptance tests, the design is emergent, and the UX is developed 'in collaboration' with our marketing team and customers.

Your post suggests that you want to have a sprint to detailed analysis and design, then a sprint to deliver, sounds very much like a waterfall approach to me.

Our planning sessions vastly improved as the product owner got better at defining requirements and acceptance criteria in advance of the planning session.