5 story point ( 3 for Dev and 2 for QA ) - do you keep track of QA and Dev story point split up in each story

The Developers are collectively responsible for making their own estimates, because they are jointly accountable for ensuring their work will be Done.

Why then would they wish to "split" and "track" their estimates in the way you describe? What purpose would this fragmentation of their estimates serve? Might it reflect a lack of consensus, teamwork and collective ownership?

Perhaps it would make more sense for them to monitor their Sprint progress in terms of a technical plan. A task burndown, for example, is commonly used for this purpose.

Scrum does not care about job titles.  It cares about the roles of Product Owner, Scrum Master and Developer.  A role describes responsibilities that need to be accounted for in order to produce a result.  If your organization uses different job titles matters not, as long as the role responsibilities are being covered.  Scrum also does not provide process as it is a framework.  So how your organization chooses to organize the work is also outside of Scrum guidance.

So, if I apply that knowledge to your original question, I am reading you ask this question instead. 

How do you use Story Points to keep track of all the different types of work that is needed to have an item reach Done?

Since Story Points are not referenced in the Scrum Guide and the Scrum Guide does not provide instructions for how a team's process should work, I'll say that you should be asking your Scrum Team that question because they are the only ones that can provide an answer.

However, the Scrum Guide does provide some ways to ensure that they correct work is being done. 

Definition of Done

This definition provides common understanding within and outside of the Scrum Team as to what it means when the Scrum Team says "this piece of work is Done".  It can contain statements such as "all new code has been tested" or "all new functionality has been verified to work correctly and no existing functionality has changed in ways that were not intended".   Those kind of statements help to communicate that a level of testing is being undertaken while the code is being changed.

Sprint Goal

This goal provides guidance to the Scrum Team about why the current Sprint is happening.  It also allows people external to the team to understand the same thing.  

Sprint Backlog

This is from the Scrum Guide.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The "how" will provide enough detail for individuals to understand what work is being undertaken.  However, since that is a process related question, the Guide does not provide anymore guidance and it is up to your Scrum Team to decide how that will be accomplished. 

My answer would be No. An individual is never an owner of a Story or PBI, they care collectively owned by the Team.

If individuals start keeping track of only their individual estimates would they not feel responsible only for their part and not the whole story or PBI collectively?

Of course Dev and QA can get together to estimate the length of a Story or PBI but they have to be collectively responsible for the estimate.

I am aligned with the primary question here, as its not a question related to anyone's integrity or trust or job title etc. Please find a below problem statement:

Scenario:

A sprint comprises of multiple tickets (a few Dev heavy, a few UI or QA heavy and a few not needing any involvement of Dev / UI folks). Now if we tend to give consolidated story points there, considering a ticket to be effort intensive for either of the role, we may end up reaching the velocity with a capacity wastage as well. Ideally as a scrum master the objective should be to have the best utilization of actual capacity available.

e.g.

Scrum team comprises of Dev, UI/designers and QA.

Sprint has 2 QA heavy tickets (story points 13 each, no Dev effort, UI effort 5 each story points), this will lead to a wasted 26 and 14 pointer dev and UI capacity respectively.

While if we estimate the tickets at 8 story points instead, then it will lead to an overload on QA for 10 story points and would still incur a wasted capacity of 20 and 6 story points for dev and UI respectively.

In my opinion, you do not have a team. You have a group of individual specialists that work together in some fashion.  If you had a team of people that were committed to doing all of the work necessary to deliver a quality increment, they would do whatever work needs to be done and not just the work that they specialize in.  For example, why can't a developer do the QA work on something that another developer coded?  

These are the opening paragraphs of the Scrum Guide's section that introduces the Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Your description of the Scrum Team has sub-teams. They are not focused on the Product Goal, they are focused on doing work that their job description says they do.  

What Daniel said.

Also regarding...

Sprint has 2 QA heavy tickets (story points 13 each, no Dev effort, UI effort 5 each story points)

How do you know there is "no Dev effort".

I assume QA in this case refers to testing. Testing may uncover defects. Particularly with "QA heavy tickets". Until defects are addressed and an increment is releasable/released, work is not Done. More development may be needed to address issues found.

Regardless of roles, and how this team is structured, the work of every team member overlaps. Testers prepare tests while coding occurs, and could be testing during this time. Coders will be addressing defects during testing and so on. Sizing of backlog items ought to take into account everything that is needed to reach Done as a single estimate.

It's better to estimate a story as a whole by the entire team. Dividing it into subsets of skills will beat the purpose of story point estimation which is intended to be used in velocity to assist the "team" to forecast how much work "they" can "deliver according to their DOD" (not just Dev or QA part of it) per sprint.

Here is a good primer to help your team aligned w.r.t backlog refinement and its intended purpose- https://scrumtrainingseries.com/BacklogRefinementMeeting/

Scrum Does not have any Roles its having Accountabilities. Also as per scrum guide there is no such mandatory methods mentioned for Estimation. However Scrum do have definition of done, to meet definition of Done whatever collaborative work(irrespective of who is doing) required we need to do.

So we should be focused on collective work which require to meet DOD not individual effort.