Sprint cycle

A Sprint is a timeboxed container that includes all of the Scrum events, the development effort that moves toward a potentially releasable Increment, and the refinement of Product Backlog Items that represent future work for the Development Team.

At Sprint Planning, the team will look at their recent past performance and forecast their capacity for the upcoming Sprint. The team's capacity includes allocating time for Product Backlog refinement plus anything that may reduce the ability of the Development Team to work - it could be anything from vacations to off-site training to known meetings that exist outside the Scrum process. Going into Sprint Planning, the work should already have been estimated in whatever methods the team uses - the team should be able to easily determine the size and/or effort of Product Backlog Items and select an appropriate amount of work for the Sprint.

The work done by the Development Team is inspected by stakeholders at the Sprint Review. This means that, when planning their Sprint, the Development Team needs to consider everything that is required to get an Increment to their Definition of Done at some point before the Sprint Review. The idea is to bring an Increment that can be considered "Done" to the Sprint Review, even if all of the selected Product Backlog Items for the given Sprint are not "Done". The unfinished work can also be reviewed as part of the Sprint Review.

So, yes - you do need to consider the timing of the Scrum events when you consider the capacity for the Development Team. You probably can't be working on getting an Increment to a done state while simultaneously inspecting it, so you need to account for finishing the work at some point before the Sprint Review starts. You'll also need to consider that you'll be holding Daily Scrums, Product Backlog refinement, and doing things that may be unforeseen when you plan your Sprint.

I wouldn't concern yourself with how much to estimate if this is your first go-round.  My experience with new teams is that we always over or under commit in Sprint 0.  Teams need time to get used to how much work they can actually finish, coupled with the variation of estimation points from team to team.  One team may look at a single line CSS change as a 1 (or 0.5) while another may say its a 2 (because of predetermined standards).  

I always encourage my scrum masters to do what "feels right" for Sprint 0.  If you're worried about underestimating, keep a list of small tasks at the top of the backlog to "pull in" at the end.  Otherwise, when you are done with the first couple of sprints you should be able to look back and see how many points your team can actually get done during a sprint.  Ultimately knowing your points per dev per working day will give you a pretty good idea of how much your team will be able to complete.