1. Really this is not the point of a framework...you could in fact create your forms to pull from an SF BO and use everything from the business layer back, but StrataFrame is not a dynamic UI generator....and in fact, I would be really curious how this would actually work past a grid since when you get into a larger application there could be hundreds of fields and grouping, form design, and layout are huge elements....so this isn't something that we really every plan to do with SF.  However, if you have this need, you can clearly use SF to help you with all of your binding, BOs, and data layer needs.
2. This really has to do more with the design of your application than the framework.  If your application has this need then you can do this with SF.  You can actually pull in any information from any table that you want...even if the strong-typed fields are not created on the BO.  So yes, you could definitely do this.  In regards to attributes, this is really more of a reflection side of things, but you could definitely get it done.
3. In this case you may want to create a custom DbDataSourceItem that talks to your DAL.  So you can do this, but if you are going to be using some other data layer, then you need to have a root SF datalayer that talks to yours to serve up data.  You can create a DAL in SF to talk to anything...even a BTrieve or binary file if you really had the need.

I agree with Trent. I don't ever see a generated interface working for anything other than a small application and it would never look as good as one crafted by hand.

Even if StrataFrame offered this feature tomorrow I would never use it. For the record, creating forms in SF is really sweet! The whole process from adding a new field in BO through to the form is not a big deal. It is REALLY a clean process. I am still learning SF but I can do things in it much faster than in my previous system - in fact the previous system is in the bin and will NEVER be used again.

Many systems say great things on their websites. StrataFrame does exactly what they say in a very clean and efficient way which is not the same as some of the others on the market.

Just my two cents worth.

For the last 10 years I've been very involved with the Visual FoxExpress framework and have dealt with these kind of requests and questions about automating the creation of interfaces.  FoxExpress is a terrific rad tool with great wizards and builders, but that is not the most important part of the framework.

We do in fact have a wizard that takes the collection of fields in a particular business object and throws controls and labels on a presentation object (like a form)   It is not re-entrant - that is you do it once when you create the presobj, but afterward if you want to add additional controls you drop them on and bind them yourself (exactly like SF) 

Frankly, while it is convenient, you still have to arrange the controls, decide which ones you want and which you don't want etc.  It really doesn't save a lot of time in the overall scheme of things.  Maybe 5-10 minutes on a form with 30 fields, if that.  You really want human intervention in interface design

I would much rather the framework builders spend their time on designing things like access to the data layer through business object, issues of performance, localization, security and handling issues that I wouldn't even think of ... and I'm continually impressed with what a good job they have done in the really important areas of framework design. 

The more you work with a framework, the more you come to appreciate the important stuff that it facilitates.  I'm very impressed with Microfour's priorities in the evolution of Strataframe.