I would think they will have the same problem distinguishing names with the current setup. If the asterisk is a delimiter of some kind, then it could be useful to determine how to split the data. This is just theoretical since we don't know what the real data looks like, or the business needs ..... I just hate seing this kind of thing. Many years ago we went through a very similar cleanup, splitting a single name field into multiple fields.
Yes, it's always a difficult thing to deal with. I don't know why it's ever done, especially these days. It's not a new problem, this kind of thing has been a known boo-boo for many, many years...decades. We haven't even touched on the ethnic issues, where some ethnic groups place the surname first.
Years ago one of my first big contract jobs involved taking over and finishing a FoxPro database and application at a collection agency. The previous developers seemed to have broken just about every good-practice rule in the book! They had names stored as in this example, they had blank name fields, they had blank key values (there seemed to be no enforcement of keys at all), they had zip codes stored as numeric values, they had empty city and/or state columns, they had payment history dates that were several years into the future or so far back in time that people's great grandfathers must have made the payments - when they were teenagers, they had empty due dates, they had multiple duplicate records. There didn't seem to be any validation of any columns. And the worst one? They had all this test data in the live system when it wasn't really fit to do business with yet!
It was really difficult trying to fix the problems while the system was in use. You have to deal with what is given to you, but man! The logic was so bad that after a while I told my boss that it was best to rewrite it from scratch. He agreed and told the agency, who didn't care as long as we got it working for them.