Using strategy objects in the described way is a good start to simplify your `PointBase` class, I would not hesitate to introduce them even if they do not solve your problem with the `BreakEven` property. 

For allowing custom properties, you could provide some kind "extension mechanism" in your `PointBase` class (which I would rename to `Point` after the redesign). In the most simple form, this could be just a list of custom properties for each `Point` object, together with a list of their values. This might boil down to some kind of [EAV model][1]. EAV is sometimes seen as an anti-pattern, but for this specical case its usage is fine as long as you do not use it for the majority of properties, only for your "special custom properties". 

See also [this former question on "Programmers" about custom fields][2]. In my answer there, I mentioned [Martin Fowler's book "Analysis Patterns"][3] - I am pretty sure it will help you for your problem, since it contains a very extensive discussion how to model measurements and observations, including (custom) properties and similar things. 


 [1]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model
 [2]: http://programmers.stackexchange.com/questions/148551/design-patterns-strategies-for-custom-fields-data-types
 [3]: http://martinfowler.com/books/ap.html