Well there is no inherent issue with changing values of a Scriptable Object at runtime in Unity. Some people might not like it for stylistic reasons but it's certainly possible. But I don't think that is what is causing you problems in this case.
The issue you are running into is specifically with InkObjects and where they "live."
The InkObjectLibrary can only be modified while authoring the game/story. InkObjects is a tool which can be used to populate your Ink story with data that can be manipulated in Ink and read back by Unity. But once you export your library to Ink, your InkObjects live in Ink and can only be modified in Ink.
If you notice that the InkObject asset in your Unity project is grayed out and not editable during play mode, this is because there is a custom UnityEditor for InkObjects that is doing that manually and reflecting the values from the Runtime instance of that Library Object. This is because changing the Library Object after exporting the Library to Ink will have zero effect on your game (apart from being very confusing).
If you want the user to modify the player character, that will need to happen in Ink, just like any other part of the Ink story. I know some things might be difficult to achieve (for example text entry) but many things will be easy to change interactively within Ink through choices. Your app could skin the choices to make it look like a more typical character design interface.
I will look into potentially expanding the InkObject system so that you can push overrides to InkObjects from Unity to Ink at runtime. I agree that would be very useful, though in my basic research into Ink my understanding was that pushing data to Ink was unsafe (for example, the Ink docs do not recommend changing values via external function).