1. In my world, we generally do not assign task to indiviual / pair during planning. We look at the prioritized product backlog and do estimation for each top stories. And based on the past sprint velocities and commitment from each members, we will decide which stories will go into the Sprint Backlog. 
   
   During the standup, individual or pair will pick the story that they would like to work on.
   
   
2. 1. Scrum dictate that each tam should be 3-9 team. 
      
      Below there's an article that study the ideal size for a scrum team to be productive. 
      
      https://agilepainrelief.com/notesfromatooluser/2016/10/choosing-the-team-size-in-scrum.html#.XH-JTs8zZQI
      
      For a team size of 3, it should be expected to perform as a Feature Team (where all members are cross-functional and cross-component). QA role can do dev, Developer role can do QA. 
      
      As such, dividing them into 3 teams (4,3,3) is totally workable. But realistically speaking, I would do that only if there's a clear distinction of the product where there's 3 very related tracks. Else, it will require lots of coordination between multiple teams. I would start off with 2 teams, and when they are matured and consistent, then could consider reform them, get them to pair with someone from another team, learning will happen and the team will be stronger. 
   2. Putting all the QA in a team are suggesting the team will only do QA. There's nothing wrong by splitting the team by component/ role, but there's indept discussion on this... You may find it useful...
      
      https://www.scrum.org/forum/scrum-forum/5563/feature-teams-vs-component-teams
3. Yes, this is the recommended way to run a Daily Standup.... for a start.... 
   
   Once the team are getting familiar and see the benefits of the standup, we can use different methods to achieve the same, if not better, value out of the activity. Below is an article that talks about Shu Ha Ri on Agile Adoption Pattern. You might find this articule useful. 
   
   https://www.solutionsiq.com/resource/blog-post/shuhari-agile-adoption-pattern/

Lastly, my advise is to continue to experiment and try out different ways and method with your team.Scrum guide serve as a good starting point (but stick with the principles) for a new team, each team will eventually evolve and each will have their characteristics and ways to run certain ceremonies. Have fun, and don't stop experimenting! 

I think what Simon said is quite right. One of the best features in Scrum/Agile is that there is no real 'right or wrong'. If your team find Stand-ups a bit counter-productive, then don't have them. Find a more suitable way to get daily updates. As a Senior BA, I use to sit with my Dev team - so I knew where things were, what was happening and when they had questions. It also allowed Devs and Testers to speak easily and openly to me, as I was sat with them. You pick up problems far quicker and you can resolve them before they turn into a disaster.

The point being - do it how it works best for you. If you get all the information your team needs to work correctly, it cant be wrong.