Classic example of users dictating technical solutions. 
This could easily be done with a picker then the model need only have 1 property, the raw value assuming text binding and data-format work together fine.

Should it really be a discussion about Kendo's version of MVVM? It is not constructive to tell people not to use Kendo here but use Knockout instead. That adds no value to making Kendo better.

Wasn't this suggestion more about supporting writable computed/dependent observables? 

I've made an example of how this can be achieved. Please see:
http://jsfiddle.net/fhuiskamp/8DzRD/7/

It adds a 'ObservableFunction' to the kendo.data namespace which can be used on any function in 2 ways:

fullName: function () { ... }.observe()
or
fullName: new kendo.data.ObservableFunction(function () { ... })

Please see the source for more info.

One place we used writable computeds with Knockout was in input fields used to capture large numerical monetary values. Users wanted to be able to input '10m' to represent 10 million. So, we bound the input to a computed. When the user entered 10m, it parsed the string into 10000000 and set that on the underlying observable (as a number).

However, was also wanted the computed to work in the other direction, so that when the page was loaded, we set the value on the observable (as 10000000), which was then formatted to 10m by the computed.

We could have done the parse and format server-side, but was also needed the numerical value client side, for validation (e.g make sure number wasn't bigger than another number that had been entered elsewhere)

Finally, the bidrectional computed helped in this situation: User types in 10000000, the computed parses this (as 10000000) and sets it on the observable, which triggers a change in the observable, which causes the computed to re-compute - as '10M' - which updated the text box after the uses moved out of it. So it implemented an auto-formatting of numbers that users typed in

This is just one of oh-so-many Telerik's design drawbacks.
After working (being forced to) with their products for years, I would strongly recommend to not use them at all if possible.

In the meantime, good sir Remo has built a nice Knockout-izator for Kendo here: http://rniemeyer.github.io/knockout-kendo/

Beware: because Kendo controls don't support "active" templates (yet another significant drawback), Remo had to trick it into processing Knockout bindings. When Kendo tries to render a Knockout-based template, Remo returns it a text "marker" (looking like "<!-- [template_12345] -->") and then, after Kendo has returned control, Remo picks out these markers and replaces them with instances of Knockout templates. This has a potential to create a performance penalty when overused.

Really would be better if Kendo just focused on supporting a MVVM framework rather than writing their own. It won't be as widely used or as good as the mainstream frameworks. Just stick to Knockout etc. 

Example link: http://www.kendoui.com/forums.aspx/kendo-ui-framework/mvvm/access-value-of-dependent-method-after-binding-in-javascript.aspx

It added the ")" at the end above.

Kendo's MVVM needs to support dependent and computed observables to further assist the UI logic.  As the business rules get heavier with each revision, the lack of these types are forcing to use more spaghetti jquery code to compensate.  [The example below is simple, and designed in part to be in a stand alone JS file that makes the ViewModel available to all functions contained within.]

In my example (http://www.kendoui.com/forums.aspx/kendo-ui-framework/mvvm/access-value-of-dependent-method-after-binding-in-javascript.aspx), I have a firstName and a lastName observable, with a dependent called fullName.  The fullName dependent observable should be updated any time the firstName and lastName observables are updated (automatically).

Here is the version working with KnockoutJs: http://jsfiddle.net/piercove/S6Q8D/2/

Here is a workaround with the current version of Kendo MVVM: http://jsbin.com/AZiSopO/1/edit

The workaround essentially is forcing the "change" binding onto the view model, which is ok for a work around, but should be built into the framework to be automatic.

Following scenario: In my viewModel i have a field with type Date. How do I parse input from user back? with writable dependent it would be possible:
var viewModel = {
    value : new Date();
    displayValue: { getFunction(){
                               return //format value to string;
                            },
                             setFunction(){
                               value = //parse entered string;
                             }

}