I don't think either options is ideal.
The problem with keeping is as 'save' is that the user has already performed an action. The user now expect (or predict) that something will happen. Now the error message shows, but now the user has to gather they need to use the same button for something else - to confirm they wish to save. This is confusing, and I wouldn't be surprise if some users will initially think that pressing the save button again will bring up the same error message.
Yes, save anyway
'Yes, save anyway' obviously solves most of the issues above, but can also bring about confusion. First, the eye may be drawn to the red warning, and initially the user will miss the caption that has changed. So the user still thinks that the save button is just save.
Also, I think 'Save anyway' will suffice here.
One control, two actions
In essence, the core of the problem is that you are reusing a control for two different actions: save, and confirmation. User may experiences slight mis-orientation.
Based on my experience with user testing, I fail to see users not completing the task - particularly with the 'Yes, save anyway' option, I reckon all users will figure this one out, and many with relative ease.
It's just that it will take some users some extra time to work things out, which is a core concept in usability - the amount of effort users have to expand (cognitive or physical) in order to perform a task.
Other usability issues.
Before the error message shows, 'Save' means save, and 'Cancel' means I want you to ignore my edit.
But once the message is shown, 'Cancel' can be easily mistaken for 'I've made a mistake and I want to correct it'. So the function of the 'Cancel' under this condition is ambiguous.
In fact, if users wish to correct their mistake, I assume they'll have to click on one of the fields, in which case the error message will disappear and the save button caption will return to 'Save'.
All in all, I think the whole process is not the neatest.
In IA this sort of journey is realised with a pattern some call 'dead-end navigation', meaning on the user is now faced with some (modal) dialog and can't do anything with the system until making a choice (thus dead-end: you can't go anywhere other than back to where you came from). Essentially this:
Since you've mentioned the interface is already a model, you can result to a popup, something like this: