I really like this question because how often I have found myself dealing with teams struggling with similar problems. Your question also points to a handful of very important agile development concepts like estimating using story points, velocity and the definition of done.
I will answer as concisely as possible.
How do you define user stories that are completable by the end of sprint?
User stories are broad by design to encourage emergent design, in-person team collaboration and more importantly to eliminate waste, common in traditional project management where requirements documents are prepared and signed off before anything else is done.
So encourage your product owner to write user stories broadly as now. However, make sure you encourage product backlog refinement throughout the sprint such that before the next sprint planning meeting, the high value user stories (that the product owner hopes would get delivered during the upcoming sprint) are decomposed with enough details to meet the team's agreed Definition of Ready (DoR). Then, during the sprint planning, the whole team further decompose each of the user stories selected by the development team, who would obviously add the technical sub-tasks such as UI design, back-end design and so on.
Like DoR, the team must also agree on the Definition of Done (DoD). Stories that meet the definition of done by end of the sprint are considered "done", everything else goes back into the product backlog, and might end up getting selected again by the product owner depending on business priorities. Obviously, each story may also have an acceptance criteria that would need to be met like the DoD.
How does pointing work in team where everyone has a specialty?
Firstly, I assume by pointing you mean the "estimation" using story points. If not, please comment and I will update my answer accordingly.
So in agile, estimation is not done using man-hours or man-days as with traditional approaches. Story points are abstract, again by design. There are lots of benefits for using this type of estimation but two of the ones I like are:
- Story points allow developers of different background (junior, senior, UI, back-end, architect, tester and so on) have a common unit of measurement, if you may.
- Story points encourage rapid estimation, for whatever it is worth, without wasting too much time on a non-value adding activity.
So, during the sprint planning, let the team collaboratively estimate. Getting this right or wrong doesn't matter. There are many techniques to allow this, with planning poker being the most common.
How can you in turn use this pointing with velocity in this case?
Velocity is pretty straight forward to calculate. You take the sum of the completed story points in the last sprint (or average of the last few sprints) and that is that. Again, velocity is simply meant to provide an indicator to the team of how much work they can manage per sprint. If they do more, great. If they do less, let them discuss it among themselves. Nothing else.
Your goal as Scrum Master should be to encourage your team to become more and more cross functional. This is exceptionally difficult but only a team with minimal specialists become truly efficient and almost without waste. You should read about ScrumFall, a common problem in Scrum/Agile teams that you should work to keep away from your team.