To answer your question directly, you can with a scrum master or senior developer dictating this, but shouldn't.
It sounds like you are at the start of an agile journey. It is the Scrum Master's job to enforce the rules of Scrum, which is exactly what you need at this stage. Over time the team will get better at discussing and distributing tasks, but will need some encouragement to start with.
As a scrum master in this situation I would:
Ensure stories are split into tasks that are smaller than half a days work for one person, and estimated in hours at sprint planning. This means everyone can see progression (or none) quickly and clearly on a daily basis.
Ensure that at the stand up every team member commits to deliver an appropriate amount of work. If they don't, ask them why they won't commit to more, and don't let them avoid it unless there is a valid reason. This is the crux of the issue. With a team I worked with in the past we even marked our daily committed tasks with a dot, so we could see if we under delivered the next day.
At the stand-up the next day if people haven't met their commitment, get them to update the estimate to how long they think is remaining. Ask why they didn't get it completed and offer help from others, but make sure to do this with concern, not anger. Do not pass their tasks off to other people, but offer them all the assistance they need from other developers that could help.
Use the burn-down chart as a discussion point at the stand-up and ask the team how we (not they) can get the top priority story (or the sprint goal) done, but do not allocate work to them yourself. You shouldn't really get hugely behind if the estimates are ok and you are following the steps above, but if you do it is a talking point for the retrospective. Is it distractions? Was it too much work in the sprint? Was it risky work you didn't think about enough? Absence? Learn from it.
I don't think you should allocate tasks any more formally than this, but at the early stages it is important to track them. Whether you link this to people (names on tasks) is up to you, but I prefer not to as it encourages team input into a task and a less individual mindset, and also reduces the feeling of being monitored as a developer.