Should user stories be assigned to team members

Are the Business Analysts part of the Team? If so, then consider that the Scrum Guide is pretty clear on not dividing the team into roles:

• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,
• Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

As such, either the BAs are equal members of the team, and thus their work is too, or they are not and it is not. If they are part of the team, and there is a task with a measurable goal (you know when it's "done"), then it is a viable task in the Sprint Backlog.

Moreover, a User Story is a story about functionality the user is asking for. It is not a list of work to be done, as such. So again, what you are talking about isn't really a "story".

So, on the practical side, I'd suggest that you include folks with business analyst skills on your team and use them to help complete your stories. The team won't know everything about a story before they start on a story--they just know there's something they need to learn about and solve. The ones with business analyst skills are going to be really helpful in elaborating the stories and translating business speak to something that can be coded and tested. If, during sprint planning, you determine there are analysis tasks to be done, add them to your sprint backlog and have someone work on them.

Ideally, your software should be bug-free after each iteration, and fixing bugs should be part of each sprint, so the work required to fix bugs should be considered when assigning story points (i.e., a task that is more likely to produce bugs should have more story points assigned to it).

In reality, however, bugs surface post-deployment all the time, no matter how rigid your testing; when that happens, removing the bug is just another change, a feature if you will. There is no fundamental difference between a bug report and a feature request in this context: in both cases, the application shows a certain behavior, and the user (or some other stakeholder) would like to see it changed.

From a business perspective, bugfixes and features are also the same, really: either you do it (scenario B), or you don't (scenario A); both scenarios have costs and benefits attached, and a decent business person will just weigh them up and go with whatever earns them more profit (long-term or short-term depending on business strategy).

So yes, by all means, assign story points to bugs. How else are you going to prioritize bugs vs. features, and bugs against bugs? You need some measure of development effort for both, and it better be comparable.

The biggest problem with this is that bugfixes are often harder to estimate: 90% or more of the actual effort lies in finding the cause; once you have found it, you can come up with an accurate estimate, but it is almost impossible to judge how long the search will take. I've even seen a fair share of bugs where most of the time was spent just trying to reproduce the bug. On the other hand, depending on the nature of the bug, it is often possible to narrow down the search with some minimal research before making an estimate.