Knack does not currently support field aliases. Instead, Knack promotes the use of humanized field names from the get go, e.g. 'Customer Address' instead of a more traditional database field name like 'CST_ADDR'. This is because Knack generates its own DB-friendly fieldnames behind the scenes (e.g., field_106, etc) and handles your field name as a 'label' attribute.
However there are many situations when you do not want to use humanized field names in Knack, such as when you are integrating the Knack data with information stored in a traditional database. For example, if I store customer addresses in a local SQL database with the field name CST_ADDR, merging customer data from my Knack DB is much easier if the Knack field label matches the field name in the SQL database.
The problem is that using non-humanized field names in Knack means that you have to manually rename all of your field names whenever you create a new view in Knack. This can be extremely time-consuming when creating views for a large application.
Support for field aliases would allow us to use our ugly, integration-friendly field names while avoiding the need to rename fields when creating user-friendly views in our app.