(1) Tasks are the steps towards the goal of a user story, similar to steps in a recipe. In both cases there are dependencies what to do when and in what order. The key is that the team talks about how to split things to work most efficient. This is not one person's job, but the Scrum team's. This happens initially during sprint planning when user stories are tasked out (by the whole team), but also daily as work is being done (daily standup etc.).
The skill is not really about finding tasks with no inter-dependencies as much as it is to minimize the dependencies and to organize things in an optimally for team efficiency. This is the team's responsibility. A Scrum Master's job is to mentor them in this direction.
(2) In Scrum (agile) you don't do architecture up front. That doesn't mean there is no architecture work in agile. On the contrary, architecture is done continuously throughout the whole project. From the start there are loose concepts and containers of ideas how to do things, and later on in the project this shell is filled with concrete architecture, bit by bit as needed by the user stories being worked on.
With regards to learning, this is true in any case, agile or not. In agile you learn the whole time. Not upfront. In the first few sprints there might be much less user stories picked as the team needs to learn new technology and other things, but the essential thing is that something shippable needs to be taken on every sprint. This has several benefits because the team can try both architectural ideas as well as their skills harnessing a new technology. Over time, this alters and the team will have a pretty good idea what the overall architecture looks like and how the technology works to pick more user stories.
My last advice is to not take over any constraints from waterfall like Q1, milestones etc. that say architecture is done by then and then. This is counter-productive and will fail. Stay agile (or not)!
