Usually a team self organises to work out who should do the release. In some teams there are team members that specialise in releases. Other teams share the responsibility around.
Typically I would not expect a team to estimate separately for a release. This is because in Scrum the definition of done often includes the release. Which means that the time taken for the release should be factored in to the estimates for individual stories.
It is quite common to have a task that tracks the release. However, this depends a lot on the effort required to do the release. Some teams have a very slick release mechanism and so do not feel the need to track releases as separate tasks.
As you rightly point out there is a risk that the release will be delayed for some reason. When this happens it can be very disruptive, both to the planning for the next sprint and to the business generally. Once again, if the definition of done for stories includes release then failing to release within the sprint should impact on the team's velocity.
I have seen a lot of approaches to releasing strategy. Some teams release on the last day of the sprint. Other teams release a day or two before the end of the sprint. It is also not uncommon for a team to have a staggered release so that work for each sprint is released in the subsequent sprint.
What this highlights is the importance of a quick and simple release mechanism. Automating releases can be hugely beneficial to a team. This is because it reduces the time that the team spends releasing and reduces the risk of disruption due to release problems.
It is worth considering making a business case for automating your releases. For example, say by automating your releases you can save 5-6 hours of effort per sprint. Over 10 sprints that would save 50-60 hours of effort and would also significantly reduce the risk of disruption. If the team was to spend 40 hours effort automating the release process then it would pay for itself in 10 sprints or less.