Tasks vs Stories

My understanding is that the Product Owner is responsible for creating (and prioritizing) the User Stories that are added to the backlog.

There are a few points to consider.

First, Scrum does not specify how Product Backlog Items are structured. User Stories are a common method, but not the only method. There is also nothing that states that all Product Backlog Items need to follow the same format. A lot of how to structure Product Backlog Items is left to the organization and team to decide.

Next, the Product Owner is accountable for managing the Product Backlog. They can choose to delegate the work to the Development Team or share the work. There's a key difference between responsibility for and accountability for ensuring that work is done.

Finally, the Product Backlog is ordered, and not prioritized. Priority can be considered when ordering the Product Backlog Items, but one that is seen as a lower priority may block one or more higher priority items. Priority can also be seen differently by different stakeholders. Ultimately, the order of the Product Backlog should give visibility into what is seen as the next work for the Development Team and optimize the value of the work delivered by the Development Team.

Where do the Tasks go? Separate JIRA items or within the JIRA for the story

Specifically in Jira, you can have different issue types. Issue types can also have subtasks. It's up to you (meaning the organization and/or teams) on how you take advantage of issue types, the form fields associated with each issue type, and workflows (which may vary by issue type) for a given instance of Jira or Jira project.

In Scrum, the Product Backlog represents "everything that is known to be needed in the product" and is "the single source of requirements for any changes to be made to the product". I would consider the characteristics of a good requirement and INVEST. If the work is an independent, testable, valuable, cohesive, unambiguous unit of work, that would be a candidate for a Product Backlog Item. Product Backlog Items can be decomposed, but I wouldn't expect to see these decompositions on the Product Backlog.

In Jira, I would consider the issues to be your Product Backlog Items and then would recommend using subtasks as appropriate to decompose work. I would consider the overhead of subtasks, though -  do you need separate, trackable entities in your tool to make the work visible or is visibility at the issue level sufficient for the team and stakeholders? That's a conversation for the organization and team to have.

Who creates the Tasks? The Dev team or the PO

From a Scrum perspective, the Product Owner is accountable for the management of the Product Backlog, but can delegate responsibilities. Anyone may create the records in the tool that represent the Product Backlog or decompositions of Product Backlog Items. This is up for the team to decide. However, in Scrum, the Sprint Backlog is owned by the Development Team. If Product Backlog Items are decomposed by Development Teams to form the Sprint Backlog, that is done by the Development Team and not the Product Owner. This decomposition should support visibility and transparency into progress over the course of the Sprint and should also support any replanning of the Sprint during the Daily Scrum.

@Thomas covered this really well. I do have 1 thing to add. 

From the Scrum Guide section for the Development Team

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

If the Product Owner was creating the tasks/subtasks I would consider that to be telling the Development Team how to do the work(i.e. how to turn Product Backlog items into Increments).