It's important to know why the story couldn't be broken down to be small enough. I suspect there could still be a creative way to deliver at least some of what's wanted, but it's hard to be sure without an example.
In answer to your questions
1 Story points are a useful way to help the Development Team to provide a forecast during the Sprint Planning. Their forecast should not be seen as a solid commitment, and it should be understood that forecasts can be wrong (although it's still valid to ask why a particular forecast was not accurate). Story points should only be assigned by the Development Team.
The Product Owner may use estimates and other feedback from the Development Team as an indicator when prioritizing the Product Backlog, but beyond that, Story Points aren't intended for any other purpose.
Assuming story points are respected in this way, the Development Team shouldn't feel it needs to rely 100% on them for its forecast. It can then count the total points value of previously completed work, but use its own judgement to provide a forecast each Sprint. If more or less work is actually completed, the team can learn from this, and provide better forecasts in the future.
So if a Development Team forecast it will complete stories of 1, 2, 3 and 5 points, but the 3 point story is not done during the Sprint, the Development Team knows it delivered (1+2+5 = 8) points of work, and can combine that knowledge with their judgement to make a forecast in the next Sprint(s).
2 The Development Team can monitor its own progress during the Sprint, and Story Points may be the way they choose to do this (but that's up to them, because Scrum says Development Teams should be self-organizing. They may, for example, use a burndown chart to track how far through their Sprint Backlog they are.
For the rest of the business (Product Owner, stakeholders, management etc), it would be better to look at the value that's being delivered, and assess whether the end result is good, rather than the mechanics of how many points a team puts onto the things it is delivering.
UPDATE based on your comment:
I suggest when you have stories that are not Done, they go back on to the Product Backlog, where the remaining work can be re-estimated (sometimes this will go up, e.g. the Development Team realise it's more work than they previously thought).
I recommend the Development Team understand they completed stories totalling X story points, plus they did some other work which they won't measure (because it's very hard to be sure if it's 75% or 40% or 90% complete).
The team should be able to take this information, accept that the velocity isn't 100% accurate and be able to make a better forecast next time.
No-one outside of the Development Team should care about velocity - the value of what has been delivered should be the thing they measure.
